"Helge Bahmann" <hcb@chaoticmind.net> wrote in message news:alpine.DEB.1.10.0912211630230.31425@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); } }; _______________________________________________________________