Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Jomu
Date : Sat Jun 11 2005 06:14 pm



David Butenhof wrote:
> Jomu wrote:
> > David Schwartz wrote:
> >
> >>    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.
>
> The point is that the THREADS are not "personifications" of the CLIENT;
> they're anonymous agents acting on behalf of all of the clients. The
> threads share resources (like malloc), but they COOPERATE to meet the
> server's requirements rather than COMPETING to meet individual client
> requirements.

  Making them as thin as possible we can make personifications without
hassle. As they are thin and working directly for single client (and
there is not multiplexing, client discovery by fd, mandatory access to
client data through few levels of indirection, ...), it's not so messy
to add mechanism or two for prioritizing and serializing of access for
some resources.

  As opposed to multiple-clients-per-connection where we can have some
client with I/O we would like to go faster, but it just didn't happen
this select()... Bad luck, as I said earlier... With thr-per-con,
activity on client is known immediatelly, client does it's local
processing and asks for whatever resource it needs, and that resource
we will just manage in specialized thread, instead of use kernel calls
for that, if it's critical in any way.

>
> That is, you can shuffle your request queue to prioritize client
> requests, either by the nature of the request or by properties of the
> client. You minimize the contention on the shared resources (again e.g.
> malloc) by banging on its synchronization mechanisms with only a few
> threads instead of hundreds or thousands.

  Possible through specialized mechanisms in thr-per-con, if it's
needed.

> There's a lot more detail we could explain that I really don't have time
> for now.

  ... I am reading carefully whatever I can. Would be there.
....
> You can emulate this somewhat in thread-per-client by making all clients
> wait their turn before making malloc calls, or IO system calls, etc,
> until your "client scheduler" says it's time (perhaps by signalling a
> condition variable); but that's far more complicated and messy; and
> involves a lot more context switches to do the same work.

  And that lot is simply not impressing me. 15000 context switches per
second brokes no sweat on $100 P4 CPU.

  dd

.