ltiprogramming, locking and
synchronization. The difference that I'm trying to achieve is that the
eager queue is implemented in hardware by finite state machines called
QCells. These are fairly simple and run independently of their clients
(processors in this case).
When a processor has been scheduled
Hi, Jason,
> I see multiprogramming as bad as any real sense of
> time is lost and all the problems of locking and synchronization arise.
How do you deal with the following scenario:
Consider a file server: it must handle multiple simultaneous
requests; it has shared meta-data needs to be update
At Thu, 30 Oct 2008 20:56:31 +,
Jason Cozens wrote:
> My main point is that processors should not be kept busy when it leads
> to a bad programming model. This bad programming model as I see it is
> multiprogramming.
What is different about EQP that it, unlike multiprogramming, res
Neal H. Walfield wrote:
> Hi Jason,
>
> It seems like you've put a lot of thought into this and come up with
> some good ideas. Thanks for sharing them with us!
>
Thanks for the response. Sorry for any delay in replying but I work for
a bank and during the day I have no way of sending personal
Neal H. Walfield, le Thu 30 Oct 2008 13:11:58 +0100, a écrit :
> > The major problem is how to manage the pool of processors. This can be
> > implemented by doing away with the centralised scheduler and letting
> > each processor manage itself. The problem is now really one of resource
> > allocati
Hi Jason,
It seems like you've put a lot of thought into this and come up with
some good ideas. Thanks for sharing them with us!
At Wed, 29 Oct 2008 21:01:33 +,
Jason Cozens wrote:
> A basic assumption of most OS design that processors have to be kept
> busy is questioned
Can you clarify wh
