757
Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Jomu
Date : Wed Jun 08 2005 01:16 am

David Schwartz wrote:
> "Jomu" <dragisha@gmail.com> wrote in message
> news:1118182702.839068.297110@g44g2000cwa.googlegroups.com...
>
> >  Why would this be more competition than N-clients-per-thread, except
> > in order of magnitude?
>
>     The alternative is not N-clients-per-thread, but a pool of threads that
> handles all the clients. And the reason that's better is that you can do a
> little bit of work on several clients without a single context switch.
>

  Probably very important on VAXes, where context switches were as fast
as tape mounting :), but I am would be not so sure in O(1) environments
on multigigahertz CPU's of recent designs.

  I agree it (pool of threads each with many clients) won't hurt. But
advantage looks tiny to me.

> > Won't we loose some of threads readability and
> > clarity when we multiplex clients in same code flow?
>
>     Nope. Everybody things the way they're not used to doing things is
> harder or not as neat.

  Can be. But I would be not so sure this is the case :). If only
meeting point of code paths (as varied by client served at moment) is
one where select happens, it surely is easily doable your way. But is
it?

> > Isn't that
> > hybridization of threads with event driven programming?
>
>     The point of threads is to keep multiple CPUs busy and to make blocking
> non-fatal to the process (so you don't have to write 100% of your code where
> any blocking is a total disaster). This gives you those important
> advantages.

  I still don't see how this eliminates (or at least dwarves)
competition as compared to colaboration. Compared to thread-per-client
design. Difference is still only in some order of magnitude.

> 
>     DS

dd

.

0