Howard Hinnant <hinnant@twcny.rr.com> writes:
On Jul 7, 2004, at 9:26 AM, Michael Glassford wrote:
However, I don't see any way to avoid re-trying after the write-lock is obtained when promotion fails, and I don't see a way to prevent promotion from failing except for the suggested latent-read-lock / upgradeable-read-lock. I agree that such a lock is a good idea, but it does have the drawback of serializing all upgradeable read locks, which could be quite undesirable in some circumstances.
I've been giving the fail-able read promotion more thought...
The purpose of using read/write locks is presumably to allow concurrent reads. In such a design, concurrent reads are probably expected as the norm, else the cheaper and simpler scoped_lock is likely to be more appropriate. Given that concurrent reads are likely to be a normal occurrence, it follows that a failed read_lock promotion would also be a normal occurrence. In the event of a failed read_lock promotion, the typical strategy is to accept that you have to block for write access, and to reread (or recompute) whatever you obtained under the read lock.
If that's so, I'd have to say that an exception is a very poor choice for reporting failure to acquire the lock. I don't know whether that's still under consideration... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com