[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nptl] Re: OSDL Bug 3770
- To: nptl@bullopensource.org
- Subject: [nptl] Re: OSDL Bug 3770
- From: Loic Domaigne <loicWorks@gmx.net>
- Date: Sat, 18 Dec 2004 10:13:31 +0100
- Cc: Nick Piggin <piggin@cyberone.com.au>
- Delivered-To: "bullopensource.org:nptl"@ml.online.net
- Delivered-To: bullopensource.org-nptl@bullopensource.org
- In-Reply-To: <1102590314.3644.107.camel@decugiss.frec.bull.fr>
- References: <1102071900.14792.81.camel@decugiss.frec.bull.fr> <41B6368F.9060704@cyberone.com.au> <1102495648.3613.39.camel@decugiss.frec.bull.fr> <41B6C2D4.5040705@cyberone.com.au> <1102497754.3644.1.camel@decugiss.frec.bull.fr> <41B6D544.1010106@cyberone.com.au> <1102501896.3644.5.camel@decugiss.frec.bull.fr> <41B6D824.80804@cyberone.com.au> <41B6DA44.4020100@cyberone.com.au> <1102502987.3644.7.camel@decugiss.frec.bull.fr> <41B6DEC1.9050506@cyberone.com.au> <1102523077.3644.42.camel@decugiss.frec.bull.fr> <41B8115C.30509@cyberone.com.au> <41B82435.7020802@cyberone.com.au> <1102590314.3644.107.camel@decugiss.frec.bull.fr>
- Reply-to: nptl@bullopensource.org
- Sender: nptl_owner@bullopensource.org
- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
Hello Nick!
Hello NPTL Mailing List!
>> Ah, the problem is that when the driver thread has a higher
>> priority than the worker threads, so when the driver goes into an
>> infinite loop waiting, the able to schedule, however.
Although POSIX legally permits such implementation for realtime policy
on SMP machines, this implementation is clearly *NOT* REASONABLE.
The reason is extremely simple: the application *CANNOT* necessarily
known that it gets stuck behind a higher-priority thread (though it
could had run on another CPU if the scheduler had decided otherwise).
That's *NOT* doable to program in a deterministic fashion in such
"realtime"-environement
[
"Realtime" put into quote. I am speaking here of soft realtime, that is
an environment whose tasks scheduling follow a specific deterministic
order. I am not speaking about hard-realtime that have additional timing
constraints. Following that definition, we can say that Linux offers
(soft) "Realtime".
]
> > The driver really needs to sleep, use a mutex, use a lower priority,
>> or something in order for it to work.
NO! It is not the responsability of the application to fix that
behavior! We can in our case because 'we know', but some applications
don't!!!
The mistake done here is interesting. When you have a pool of servers,
you can proceed in two ways to serve the clients:
(1) make a FIFO queue for each server. When a client arrives, it
chooses the queue that is the shortest.
(2) make an unique FIFO queue for all servers. All clients are
queued, and when a server is done it takes the first client
waiting on that big queue.
Queuing theory proves that (2) is better. Exactly due to the reason we
have here. With (1), the guys in the queue might get stuck if the
corresponding server is blocked by a client. With (2), when a server is
blocked by a client, it doesn't prevent the other clients to be served
by other servers.
[
An historical note. USA had implemented (2) in offices, supermarkets and
such long before Europa. Because in Europe, customers were convinced
that model (2) took more time, because the queue was longer.
]
Liste de diffusion nptl
Pour se désinscrire : mailto:nptl_request@bullopensource.org?subject=unsubscribe