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



David Schwartz wrote:
....
> >  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.
>
>     It is bad practice to architect your design to the particulars of one
> implementation of a standard.
>

  Was I not clear enough with subject?

  I am writing, and from start, about NPTL and my take on earlier
explained problem of it's synchronization mechanism. Thread-per-client
is spinoff topic, but interesting to me as I think it's feasible now to
think in these terms as there are loads of cheap hardware platforms
around capable to do that.

....
> >  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.
>
>     The drawbacks of thread  per connection are numerous and you've barely
> touched on the surface of them. For one thing, POSIX only guarantees you 64
> threads. Are you okay with a design that might not support more than 64
> connections?

  But, it's not of practical interest to me. I am not implementing new
Apache so I have to think about zillion of hardware and software
platforms around. It's okay with me if my designs only work for those
50 (or i'ts 100 already?) million Linux machines around the world. I'll
live with that :). If (and I hope so) need be to reimplement for some
other system, I can easily morph my code to pool-of-threads, as it's
"client personificating" design is pretty clean and easy to
cut/paste/fool around.

> The main drawback of thread-per-connection is the you totally
> lose control over what work you do, turning that over to the scheduler.

  Oh, I've heard similar argument before. It was when some people
argued to me how user space threading is far better for some system
because "otherwise you lose control"..

  I am not afraid and I do not feel unsafe to give that control to
system. I am pretty sure some dedicated work in kernel area will make
better than me trying to reinvent scheduler for this or that. Let
everyone do it's work and lets focus on our work. Better performance
and still less work for me - win-win.

> POSIX does not guarantee any notion of "fairness" in thread scheduling, and
> you generally do need some fairness is work scheduling. So you cannot map
> threads to work one-to-one.

  How about "let's finish our work fast and leave enough CPU cycles so
other clients can do it too?" It's not fair enough? In my book it is.
Let system do rest of fairness.

>
> >>     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.
>
>     You only have the guarantees the standard gives you.

  And standard is work in progress. Watch this space :).

  Performance of current systems is reality _now_, some of it unknown
and unpredictable during consensus making process of current standard.
I would not wait for committee approval to use what is available to me
now. Esp when it's as semantically correct as possible.

....
> 
>     DS

  dd

.