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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost