Subj : Re: Futexes are wrong! (Are they?)
To   : comp.programming.threads
From : David Schwartz
Date : Mon Jun 13 2005 12:22 am


"Jomu" <dragisha@gmail.com> wrote in message 
news:1118642255.487400.283850@g43g2000cwa.googlegroups.com...

>  Was I not clear enough with subject?

    The discussion clearly has nothing whatsoever to do with the subject. 
The subject is a legacy from many, many posts ago. Any relationship to 
futexes is long lost.

>  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.

    If there was any benefit at all to thread-per-client, I'd agree with 
you. But there is none at all. Only deficiencies that you might think are or 
are not important.

>>     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.

    And it's downright foolish to pick a deficient design just because Linux 
doesn't penalize you as badly as some other OS might.

>> 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"..

    If you're going to do thread-per-connection, they're right. You probably 
are better off with user-space threading. The point is that with a thread 
pool architecture, you don't need to control the scheduling of threads 
because you control what work the threads do.

>  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.

    The problem is that the kernel does not know what you want.

>> 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.

    The system is not responsible for any notion of fairness within a 
process.

    Just please, name two advantages of thread-per-client. I've named at 
least six advantages of a thread pool.

    DS

.