Re: [boost] win32 mutex and condition variable algorithms

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-09-20 06:41:23

Alexander Terekhov <terekhov_at_[hidden]> writes:

> Anthony Williams wrote:
>> 
>> Alexander Terekhov <terekhov_at_[hidden]> writes:
>> 
>> > Anthony Williams wrote:
>> > [...]
>> >> He claims that the second A: lock takes the slow path, when it could have
>> >> taken the fast path because the lock is free. I disagree. The lock is NOT
>> >> free, since B is waiting on it. If A can take the fast path here, that's
>> >> opening the door for B to be starved.
>> >
>> > That's not a problem as long what we need is efficient low level
>> > exclusive lock. If starvation is a problem, one can solve it with
>> > custom scheduling monitor on top of "grab if you can" low level
>> > exclusive lock without handoff. Low level, all pigs are equal. ;-)
>> 
>> So let them compete equally. If A doesn't wait on the semaphore, it has an
>> unfair advantage.
>
> If you can make them both "wait" on something but without really bad 
> consequence of handoff, I'd have no problems... except that it would 
> simply add totally pointless overhead.

Yes, there's overhead in a semaphore wait, but it's not pointless --- it
allows the OS to schedule the threads appropriately. If you have contention,
both threads have to do the same thing, otherwise you've added an implicit
bias. We could just do a spin-wait if we want really-fast locks and unlocks
--- except that for long-lasting locks, a waiting thread would consume CPU
time spinning, and hence hinder the progress of other threads.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk