Subj : Re: Futexes are wrong! (Are they?) To : comp.programming.threads From : David Schwartz Date : Fri Jun 10 2005 05:16 pm "Jomu" wrote in message news:1118398031.813806.117290@g44g2000cwa.googlegroups.com... >> > 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. No! The thread gets scheduled and already knows which I/O can be done (say because a 'select' or 'poll' call has already returned). It only does non-blocking I/O to the network, so the thread can use up its full timeslice. File writes are likewise non-blocking. You should typically only see context switches on file reads that can't be predicted or cached. > 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... Of course, that's why you use I/O discovery techniques like 'select' and 'poll' and non-blocking I/O. > 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. This just isn't a problem. Yes, you will hear about people complaining that they can't get their automatic tuning algorithms to work correctly, but that's because they're aiming for perfection. It is still trivially easy to do *way* better than a thread-per-connection model can do. DS .