Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Eric Sosman
Date : Wed Jun 08 2005 02:12 pm



Jomu wrote:
> David Butenhof wrote:
> ...
> 
>>>This may force the waiting thread(s) to wake up just to find out that
>>>the condition is not true and fall back to wait on the condvar again.
>>
>>Yup. That's life in a concurrent world. But this is GOOD; because if the
>>predicate is no longer true, it means the APPLICATION (and user)
>>benefited by some other thread being able to process the condition
>>earlier than the awakened thread could get through the scheduler,
>>acquire the mutex, and so forth. Threads are cooperative, not
>>competitive; it's the PROCESS throughput that matters. If you think of
>>it that way, you'll get yourself into less trouble. (And avoid
>>unnecessarily twisting your mental model.)
>>
>>That's one reason why thread-per-client is bad; it tries to force
>>threads to COMPETE for resources, and they simply can't do that
>>effectively -- they're inherently co-dependent because of the state they
>>share.
> 
> 
>   Why would this be more competition than N-clients-per-thread, except
> in order of magnitude? Won't we loose some of threads readability and
> clarity when we multiplex clients in same code flow? Isn't that
> hybridization of threads with event driven programming?

    Here's an analogy (analogies aren't rigorous, but can
be helpful anyhow): If you owned a shopping mall, would you
hire a dedicated clerk for every customer that walked in the
door?  If you did, would there be contention for aisle space,
cash registers, and employee restrooms?

    An advantage of thread pool designs is that they allow you
to adjust the thread count to match the resources, instead of
letting the clients dictate the thread count.  The decoupling
creates an exploitable degree of freedom not found in N-to-N
designs.

-- 
Eric.Sosman@sun.com

.