Boost logo

Boost :

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2004-07-06 05:21:10

=?iso-8859-15?Q?Bruno_Mart=EDnez_Aguerre?= <br1_at_[hidden]> writes:

> What about a latent_write_lock?
> It's semantics would be to block on contruction until it only shares the
> mutex with read_locks. A write_lock could be contructed from a
> latent_write_lock and this would always work, because another
> latent_write_lock would still be blocked in it's constructor. This kind of
> lock would be useful for situations in which you have to read a structure to
> know if you have to write on it.


The RTOS we use does this --- you can have an "intention for exclusive
access", which happily shares with "shared access", but not with other
"intention for exclusive access" or "exclusive access".

Promotion is always safe (though blocking), since there can only be one
promotable lock. It also means that data read during the read-only part of the
code can safely be assumed to be valid during when you have acquired your
write lock.

void g(read_write_mutex& m)
    read_lock r(m);
    // read stuff

void f(read_write_mutex& m)
    latent_write_lock l(m); // other threads calling f will block here.
    // threads calling g will not block.

    // other threads can read here
    int const balance=get_balance();
    int const cost=get_cost();

        write_lock w(l); // block whilst we wait for other readers to finish
        // exclusive access; even threads calling g will block
        assert(balance==get_balance()); // no re-reading necessary

    // other threads can read again


Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at