At 9:31 AM +0200 8/20/02, Elizabeth Mattijsen wrote:
>At 11:00 PM 8/19/02 +0100, Dave Mitchell wrote:
>>On Mon, Aug 19, 2002 at 10:16:11PM +0200, Elizabeth Mattijsen wrote:
>> > Please note that all of these runs all did the _same_ amount of work,
>> > just with a different number of worker threads. And as the job itself
>> > is minimal, we're basically measuring overhead here. The benchmark is
>> > not measuring thread startup or thread shutdown, just what happens
>> > inside the threads themselves.
>>But your code is not using cond_wait()/cond_signal() correctly, so you just
>>have lots of clients actively fighting each other for the lock.
>
>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. 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.
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? 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)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
