Ion Gaztañaga wrote:
An upgradable mutex is efficient if the writer not always writes, but it also reads many times. In that case, acquiring upgradable lock still allows concurrent readers that have acquired sharable locks. The reader-writer can read but can also write *if upgrades the upgradable lock to an exclusive lock*. If the reader-writer realizes that a write is necessary it should call unlock_upgradable_and_lock() which blocks until all readers finish.
There is no guarantee that new readers will not get sharable lock while the upgradable lock calls unlock_upgradable_and_lock(), because all of them need to grab an internal mutex and this scheduling is done by the OS. You can only guarantee that new readers will block *after* unlock_upgradable_and_lock() has been completed.
Hi Ion, thank you for your replies. The reason why I asked if this is correct proceeding, is that I can observe the described behavior on my machine. Actually the writer is a write-only process whose writing frequency is not predictable. So I tested this: reader1->u_mtx.lock_sharable(); // does not block reader2->u_mtx.lock_sharable(); // does not block writer->u_mtx.lock(); // does block reader3->u_mtx.lock_sharable(); // does block (until the writer has finished its operation) This is reproducible on my machine so I asked myself if this is the intended behavior. It would be exactly what I am looking for. It doesn't matter to me if readers can obtain the lock just in the moment the writer initiates its locking attempt. I just want to prevent the writer from starving and give him a little more preference. Thank you very much. Moritz