|
Boost : |
Subject: Re: [boost] [lockfree::fifo] Review
From: Chris M. Thomasson (cristom_at_[hidden])
Date: 2009-12-21 12:21:39
"Helge Bahmann" <hcb_at_[hidden]> wrote in message
news:alpine.DEB.1.10.0912211630230.31425_at_m65s28.vlinux.de...
> On Mon, 21 Dec 2009, Chris M. Thomasson wrote:
>> Of course you are right. For some reason, I was thinking that
>> `memory_order_consume' would boil down to a:
>>
>>
>> MEMBAR #LoadLoad
>>
>>
>> on a SPARC. The name was confusing me. Perhaps it should be named
>> `memory_order_depends' or something...
>
> I think it was named exactly that way in some earlier proposals, and I
> also liked it better.
>
>> I don't think I can use C++0x memory ordering to achieve simple #LoadLoad
>> and #StoreStore barriers without the #LoadStore constraint. Am I right?
>
> If a hypothetical C++0x compiler were extremely clever and knew that the
> only operations on shared data before a given "release" fence were stores,
> it could translate this as "MEMBAR #StoreStore" (similar for "acquire"
> with loads).
Yes, that's a good point.
> I don't know if the required code analysis is feasible or worthwhile, but
> there is certainly no way to force the compiler to generate these exact
> barriers.
>
> It's a pity that something like the below algorithm is therefore not
> possible:
Agreed.
[...]
>
> which provides a nice, contention-free (no stores by readers!) mechanism
> to share read-mostly state.
Interesting... Humm, that kind of reminds me of a sequence lock:
<membars aside for a moment>
_______________________________________________________________
template<typename T>
struct sequence_lock
{
T m_object; // = T()
uint32_t m_version; // = 0
mutex m_mutex;
T read()
{
for (;;)
{
if (LOAD(&m_version) % 2) yield(), continue;
T object = m_object;
if (LOAD(&m_version) % 2) yield(), continue;
return object;
}
}
void write(T const& object)
{
mutex::scoped_lock lock(m_mutex);
STORE(&m_version, LOAD(&m_version) + 1);
m_object = object;
STORE(&m_version, LOAD(&m_version) + 1);
}
};
_______________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk