Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-20 06:23:40


Alexander Terekhov wrote:
> 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.

Here's TryEnterCriticalSection (-recursivity) for reference:

bool try_lock( critical_section * p )
{
    return atomic_compare_exchange( p->LockCount, -1, 0 ) == 0;
}

CRITICAL_SECTIONs have no timed_lock.

Your version can be made posix-safe at the expense of three atomic ops
instead of one in unlock:

void unlock()
{
    atomic_increment( refs_ );

    // as before

    if( atomic_decrement( refs_ ) == 0 )
    {
        CloseHandle( event_ );
    }
}

void destroy()
{
    if( atomic_decrement( refs_ ) == 0 )
    {
        CloseHandle( event_ );
    }
}

That's too slow, I guess? But maybe you'd be able to think of a way to
somehow combine the refs_ manipulation with the lock_ manipulation?

The event pool solution would also work, but the problem there is that the
pool would need its own synchronization. Unless it's an "interlocked slist".


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