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. regards, alexander.