Peter Dimov wrote:
Michael Glassford wrote:
Finally, to take two more realistic use cases:
void f(read_write_mutex m) { read_write_mutex::write_lock w(m);
//...
read_write_mutex::read_lock r(w); //lock promotion
//... }
And:
void f(read_write_mutex m) { read_write_mutex::write_lock r(m);
//...
read_write_mutex::read_lock w(r); //lock demotion
//... }
The second lock does unnecessary work in demoting/promoting the lock for the first lock, which then immediately unlocks it.
This is a very good point, since in the second example the unnecessary promotion would block.
One thing that I haven't made clear is that (so far at least) the Boost.Threads read/write mutex doesn't support infinitely-blocking promotion, which has problems (e.g. if two threads with read locks block waiting to be promoted to write locks, they deadlock); it only supports try_promote() and timed_promote(). So there shouldn't be a problem with blocking, at least, in the second example.
This seems to suggest that read_write_lock is necessary in such a scenario.
Looks like I really messed up my examples; I'm glad you could see my point in spite of that. Of course, what I meant was this: void f(read_write_mutex m) { read_write_mutex::read_lock r(m); //... read_write_mutex::write_lock w(r); //lock promotion //... } And: void f(read_write_mutex m) { read_write_mutex::write_lock w(m); //... read_write_mutex::read_lock r(w); //lock demotion //... } Mike