Alexander Terekhov <terekhov@web.de> writes:
Anthony Williams wrote:
Alexander Terekhov <terekhov@web.de> 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