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 http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk