Re: [Boost-users] [interprocess] named_upgradable_mutex

Subject: Re: [Boost-users] [interprocess] named_upgradable_mutex
From: Moritz (mokoman_at_[hidden])
Date: 2009-07-02 03:13:57

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