Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : Jomu
Date : Fri Jun 10 2005 04:07 am



David Schwartz wrote:
> "Jomu" <dragisha@gmail.com> wrote in message
> news:1118269884.989800.121510@g14g2000cwa.googlegroups.com...
>
> >I would not hire clerk for every customer, but efficiency grows as
> > number of clerks is nearer to number of customers currently shopping
> > :).
>
>     No, it's not. The clerks just fight over the cash registers and get in
> the way of the customers. There exists some ideal number of clerks at which
> the most customers per second can be served, and above this number of
> clerks, things just get worse.
>

  Lots of clerk-customer interaction happens before it hits cash
register and I prefer mobile cash register terminals anyway :). Think
tens of waiters running around a club serving customers and
communicating with bars. Tell me it's wise to keep number of waiters
down and/or raise number of fixed cash regiters up, if you still think
same :).

  Same with computing, lots of processing is far away from malloc and
i/o (esp on different fd's as it happens in t-p-c designs) is very
"parallelizable".

> > Thats one thing. Another thing, there is surely known percentage of
> > oglers in any shop - and there is no such luxury in our designs -
> > oglers are lost performance.
>
>     I'm not sure how this fits the analogy. If by oglers you mean customers
> that don't require servicing, well that's right, and that's one of the
> problems with thread-per-connection -- many of your threads are doing
> nothing.

  And, what is this exactly? A problem? Thread blocked at I/O in O(1)
scheduler. Standing alert but almost invisible. Spending few kilobytes
of VM on it's stack, and few 100's of bytes on it's in-kernel data. And
no CPU cycle.

>
> > When you create pools, you loose when, for example, two clients
> > needeing attention atm are served by same thread. I am sure this
> > situation is not so rare. Ideal would be if them would distribute their
> > moments of needed attention, but something tells me Murphy lives there
> > too.
>
>     No, you win in this case, because there's no context switch.

  I do "win" there :). There is a moment when you refer to kernel for
your I/O and that would be a context switch in huge percentage of
cases.

  Multiprogramming environments are like that. Few microseconds until
your I/O arrives is reason enough to go to next ready process. Oh, it
would not be your thread, as they are all stupified by serializing
their demands?! Too bad, other processes win these cycles. Going on...

> eighteen clients need servicing at once and you only have four CPUs. You do
> best if four threads start running and each one handles a client and then as
> soon as it finishes that client starts on another one. Having eighteen
> threads fight for the scheduler doesn't help at all.

 I like abstractions more. Making design specifically for a customer
with four CPU's and another for poorer one with two CPU is not a wise
made desicion to me. 

> 
>     DS

dd

.