Subject: Re: [Threads-devel] shared_mutex documentation request
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2012-09-04 06:35:38
On 08/07/2012 04:13 PM, Glenn L. Austin wrote:
> On Aug 7, 2012, at 6:23 AM, Fredrik Orderud <forderud_at_[hidden]> wrote:
>> I've recently struggled with a deadlock caused by shared_mutex being
>> unwilling to allow more readers to enter when a writer is already
>> waiting (running on Windows 7/x64). Code to reproduce is pasted below.
>> Prioritization of writers might be a perfectly good strategy, but I
>> could find no mentioning of it neither in the shared_mutex.hpp headers
>> nor in the boost::thread documentation webpage.
>> Would it be possible to extend the shared_mutex documentation to also
>> cover some implementation details about the reader vs. writer
>> prioritization scheme (or similar)?
> Much of this "writer blocks readers" comes from issues around multiprocessor design.
> I can simply describe it by giving an example of how multi-byte values are usually managed from the hardware level.
> Writing a misaligned value (one that isn't on a cache-line or long-aligned boundary) often requires multiple bus operations, which can be interrupted by an intervening read. So, if you have 0x12345678 in a misaligned long (split at the word boundary between 0x1234 and 0x5678) and write 0xFEDCBA98 to that long, an intervening read could actually end up with 0x1234BA98 or 0xFEDC5678 -- neither of which are values that are expected by your code at that time.
> So, if your readers don't block on a writer, you may get unexpected results -- or not. Like most threading issues, you might never see this on any machines you test against, but there is a customer out there somewhere who WILL see this issue arise with your code.
While the explanation is very clear, the OP of this thread is not asking
why this happens, he is complainig/asking for the lack of
I would add that not only mutex there is no concept of priority, they
are not even fair, so expect starvation.