At 04:56 AM 8/20/02 -0400, Dan Sugalski wrote: >>Well, I would be interested in knowing how you _should_ use >cond_wait()/cond_signal() then. I don't see how you can get it together so that the >clients are _not_ fighting for the lock(). Because that is the basic problem that I >see Perl threads now have. >There's nothing wrong with the clients fighting for the lock. That's what locks are >for, after all--to allow you to protect critical sections of code. Conditions are >only supposed to be used when you need explicit coordination between threads.
And this is such a case. But cond_signal and cond_wait pairs _don't_ coordinate currently. The only thing the cond_signal does is wake the thread that was doing the cond_wait, so it can join in the fight with the other threads for the lock. >.. They *aren't* supposed to be used as a general critical section protection. >(That's what locks are for) Perl's thread model, even with the changes, isn't much >different than the POSIX thread model. I'm not using it for critical section protection, I'm trying to use them for coordination. >It's hard to say for sure, having only seen the code you've posted with this thread, >but are you sure that maybe you're not missing something somewhere? Let me tell you that this was a reduced version of all of the other things I tried to do with threads: Thread::Conveyor, Thread::Pool, Thread::Tie. Whenever you tried to use them seriously, they would just become useless because of all the CPU they were (needlessly) burning. >... That benchmark was pretty meaningless, and the explanation attached to it seemed >to miss the point rather badly. (That might be a language issue, or a convoluted >benchmark problem) Maybe I am missing the point rather badly. And I probably only am a mediocre programmer at best. If I would describe my feeling about this, using a painter anology, is that I've been given new paint with which to create great new stuff, only to find out that the paint doesn't stick to the canvas. It's fun to have it on your fingers, but you can't do anything serious with it. And I want to do serious things with it. However bad a painter I may be. What the benchmark shows is that the more threads you create in a client/server situation, the more CPU is needed to get the _same_ number of jobs done. If you add 50 threads, it takes about 25 times as long and uses about 25 times as much CPU. I think that's an overhead that is unacceptable. And all of this is caused by the fact that cond_signal just _wakes_ the thread in cond_wait, so it can join in the fight for the lock. In my opinion, the thread being woken should _always_ _immediately_ get the lock (in the case of cond_signal). And if you are using cond_broadcast, _one_ of the threads being woken should get the lock. Currently all of the woken threads join in the fight for the lock. The pod for threads::shared state: "The two actions of unlocking the variable and entering the blocked wait state are atomic, The two actions of exiting from the blocked wait state and relocking the variable are not". Which in a nutshell, is the problem I think. If you want me to document the example program line by line for you, I'll go that extra mile. I hope I've made the problem a little clearer without the example program. Liz
