Boost logo

Boost :

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 Williams
Software Developer
Just Software Solutions Ltd

Boost list run by bdawes at, gregod at, cpdaniel at, john at