=?iso-8859-15?Q?Bruno_Mart=EDnez_Aguerre?= <br1@internet.com.uy> 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.
Yes! 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(); if(cost<balance) { 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 set_balance(balance-cost); } // other threads can read again } Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd.