Peter Dimov wrote:
Michael Glassford wrote:
To me, it just feels like the wrong way to be notified that a lock promotion failed so you have to do something else--a try_promote() seems much better for this. However, if people really wanted a throwing promote(), I'd add it.
The point is that the
scoped_write_lock wr( rd );
syntax, if supported, should never "succeed" without giving you a write lock.
OK, that makes sense. I was still thinking in terms of the non-constructor promotion model.
scoped_try_write_lock wr( rd );
can do that, but not scoped_write_lock.
That said, can you show an example that demonstrates how a 'try_promote' can be used? I'm curious.
I was still thinking in terms of the non-constructor promotion model here as well: void f(read_write_mutex& m) { read_write_mutex::try_read_write_lock l(m, read_lock); //do "read stuff" if (!l.try_promote()) { l.unlock(); l.write_lock(); //redo some of "read stuff" } //do write stuff } 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 }