> From: Howard Hinnant
>
> Exploring the case: throw exception if unable to atomically
> promote read to write:
>
> If an exception is not thrown, then you are guaranteed what
> you previously read is still true, and all is well. If an
> exception is thrown, then you have to re-read to determine
> current state.
First, to be clear, a promote() _must_ not be allowed to silently fail,
otherwise you break the contract and people will spend several days tracking
down the problem. If you want that behavior you should use try_promote().
I don't have a problem with it simply deadlocking, or, if that's
unacceptable don't have the blocking promote() function. The complexity
involved in determining a deadlock may be well beyond what you want to do at
this level in the library, I'll come back to this later.
But for now, lets talk about throwing. In my mind the purpose of throwing is
to allow the other thread (or threads, with the database work I've been
doing multiple read locks on an object all trying to be promoted to write
locks at the same time happens more often then you might think) to proceed,
which it can't do unless you give up your _read_ lock.
>
> Hmm...
>
> Given that when you have write privilege you also implicitly
> have read privilege, this seems a little extreme. Would it
> not be both more efficient and easier to follow if you just
> reaffirm your state under the write lock rather than assume
> your state, and write a catch block to reassert it if it
> happens to be false? That is, this:
>
> bool try_sale(rw_mutex& m)
> {
> read_lock rl(m);
>
> long balance = get_balance();
> long cost = get_total_cost();
>
> if (balance > cost)
> {
> write_lock wl(rl);
> set_balance(balance - cost);
> // ...
> return true;
> }
> return false
> }
>
> bool do_sale(rw_mutex& m)
> {
> while (true)
> {
> try_again:
> try {
> return try_sale(m);
> catch (rw_promotion_error&) {
> // Try the whole thing again
> // how is this implemented?
> goto try_again; // ?
> }
> }
> }
>
> vs this:
>
> void do_sale(rw_mutex& m)
> {
> read_lock rl(m);
>
> long balance = get_balance();
> long cost = get_total_cost();
>
> if (balance > cost)
> {
> rl.unlock(m);
> write_lock wl(m);
> set_balance(balance - cost);
> wl.transfer_to_read_lock(rl);
> balance = get_balance();
> }
> // ...
> }
>
> My assertion is that you don't know a-priori if the
> read-to-write promotion achieves anything or not. If you
> allow it to fail, by exception, or by error code, or by any
> other means, then you have to write code to re-read the
> current state. If you don't allow it to fail, then you must
> make it block until it succeeds. The latter seems simpler in
> logic, and smaller in code size. The logic is quite simple:
>
> read_lock to write_lock promotion is not atomic.
>
> Once that is understood, the programmer can just deal with
> it. Trying to encapsulate this bit of reality only serves to
> obfuscate the necessary logic.
The reason that "release read, acquire write" appears a complete alternative
to promotion is because your example is too simple. You may need the read
lock to keep the object alive in a cache, where it could be flushed to disk
and destroyed if you release it, forcing you to re-read it before getting
your write lock.
I think that the library should either commit to detecting deadlocks or
don't do it at all. Is it going to throw a promotion exception in this case?
Thread A: read lock x
Thread A: read lock y
Thread B: read lock y
Thread B: write lock x, blocks
Thread A: promote y to write lock, blocks
In order to detect things like this you essentially need to build a complete
conflict matrix of all held locks in the system, and if you do that I assume
you'd also use it to detect deadlocks of regular locks:
Thread A: lock x
Thread B: lock y
Thread A: lock y, blocks
Thread B: lock x, blocks
Glen
