From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-07-20 05:28:15
Peter Dimov wrote:
> Yes, I see it now. I see no protection in MS's CRITICAL_SECTION against
> this, either. It's basically (recursivity omitted)
> void lock( critical_section * p )
> if( atomic_increment(p->LockCount) != 0 )
> slow_lock_path( p );
> void unlock( critical_section * p )
> if( atomic_decrement(p->LockCount) >= 0 )
> slow_unlock_path( p );
> and it seems to me that slow_unlock_path happily accesses *p, in particular
> something called p->LockSemaphore (whether it is really a semaphore is
> another story).
Well, absent try/timed operations, that scheme is "posix safe", but
slow once you have a bit of contention. The problem is that last
"slow path" below.
A: lock [lockcount == 0]
B: lock [lockcount == 1, slow path]
A: unlock [lockcount == 0, slow path/post sema]
A: lock - [lockcount == 1, slow path]
There's no need for A to go slow path here; the lock is free.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk