Subj : Re: Futexes are wrong! (Are they?) To : comp.programming.threads From : Jomu Date : Sat Jun 11 2005 06:00 pm David Schwartz wrote: > "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. You don't read all I write, it happens... It's okay, in your model, if traffic already happened. What do you do when your select returns no-events, but in few microseconds it happens? Would you spend rest of your time slice busy waiting, just in case and to ensure no evil context switch? With non-blocking select you are actually polling your data, and it's opposed to "interrupt-driven", where every thread waits on blocked read for traffic to happen. What guarantee do you have there would be more than one fd active in your timeslice? Are there some numbers I am not aware off? Nobody pulls them as far as I follow these discussions. And without something like that, I really can't see how one can "autotune" it's parameters. As topic says "Futexes are wrong..." , signaling thread preemption can be bypassed for (IMHO) most popular use case. As JS told me before - no use when context switch is cheap if you must have more of them instead of one. But, bypass which started this topic ensures exactly that - efficient not ping-pong preemptive signaling, which coupled with lightweight context switch makes thr-per-con very much bare-metal solution. > > > 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. And, what happens when incoming data is "just around corner atm"? As I am sure it would be just enough times to make that scheme pretty unusable. "My" approach would assure consumer is right there to accept incoming data. What are drawbacks of thr-per-con. To this moment, it's banging on sync primitives for malloc and I/O (and this is not really banging as every thread accesses it's fd and it's fd only). Also, memory management is far cry from K&R one so it's also non-issue here. With lock-free and wait-free techniques for synchronization around the corner, it will surely become non-issue in short-time. What remains are these few pages of VM for stack, and few 100's of bytes for in-kernel data. With 64bit machines in consumer hardware already, and it's tons of gigabytes of VM, it's already problem of past. > > 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. Can be. Surely few years ago, with O(n) and O(n^2) schedulers and VM managers, but - it's past time too. > > DS dd .