[boost] Re: [Boost.Thread] mutex Win32 implementation changes

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. 

regards,
alexander.