[interprocess] named_upgradable_mutex
Hi everybody, I have a question concerning the interprocess::updgradable::mutex. My scenario: I have a writer, which is manipulating an object in a interprocess::managed_shared_memory. And I have 'n' readers which are reading the object in the shared mem. If the writer is ready to write, it should get the possibility as fast as possible. So this is a variety of the classical readers/writers problem and I already found a good solution that fits my requirements. But this solution uses 3 mutexes and 1 counter so I am looking for a more efficient solution. The idea is that the writer locks the upgradable_mutex normally (calling lock()) and the readers lock it sharable (calling lock_sharable()). If the mutex is locked sharable and the writer tries to lock it normally, another attempt to lock it sharable has to wait until the writer succeeded in locking and unlocking the mutex. Is this correct proceeding? Thank you Moritz
Moritz escribió:
Hi everybody,
I have a question concerning the interprocess::updgradable::mutex.
My scenario:
The idea is that the writer locks the upgradable_mutex normally (calling lock()) and the readers lock it sharable (calling lock_sharable()). If the mutex is locked sharable and the writer tries to lock it normally, another attempt to lock it sharable has to wait until the writer succeeded in locking and unlocking the mutex.
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. Best, Ion
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
Moritz escribió:
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.
If the writer succeeds acquiring the exclusive lock (and to get this, it will need to wait until all readers finish their job), then every other attempt will block until the writer finishes. That's guaranteed. Regards, Ion
participants (2)
-
Ion Gaztañaga -
Moritz