Michael Glassford <glassfordm <at> hotmail.com> writes:
Translating this to the constructor model of promotion would have to look something like this, I guess:
void f(read_write_mutex& m) { read_write_mutex::try_read_lock r(m);
//do "read stuff"
read_write_mutex::try_write_lock w(r, /*maybe a parameter here to use try_promote() instead of promote()*/);
if (!w.locked()) { r.unlock(); w.lock(); //redo some of "read stuff" }
//do write stuff }
You could encapsulate some of that in the constructor of the write lock: void f(read_write_mutex& m) { read_write_mutex::read_lock r(m); do_read_stuff(); read_write_mutex::write_lock w(r); // Upgrade, releasing and re-acquiring // if necessary if (!w.atomically_promoted()) { do_read_stuff(); } do_write_stuff(); } It certainly looks error-prone, by requiring a test and the repetition of the earlier code. Makes you wonder if it should have a function to execute on non-atomic upgrade: { read_write_mutex::read_lock r(m); do_read_stuff(); read_write_mutex::write_lock w(r, bind(this, &class::do_read_stuff)); do_write_stuff(); } You could reduce further, but I'm sure it will collapse under the weight of real code :) Matt