Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk