C++0x memory ordering question...
Chris M. Thomasson
std::atomic<unsigned> shared;
shared.store(1, memory_order_acquire);
Is that even a legal operation?
Chris M. Thomasson
news:h24sf1$the$1...@news.ett.com.ua...
Also, what is `memory_order_acq_rel' on a SPARC? is it something like:
MEMBAR #LoadLoad | #LoadStore | #StoreStore
or is there a #StoreLoad in there? Can it get away without using an `MFENCE'
on x86? How about on PPC, I assume it could be a `LWSYNC'...
I am asking this because I am trying to avoid a `#StoreLoad' membar in my
experimental work-stealing deque algorithm:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/11b38a3d2ca2a9f0
I can get the algorithm to work fine with a `memory_order_acq_rel', but am
worried that it will emit a performance destroying `#StoreLoad'! Ouch...
I can also get the algorithm to work with using a `memory_order_acquire' on
some critical stores, but I am still worried that its either no legal or it
will still emit a damn `#StoreLoad'.
Chris M. Thomasson
news:h24sf1$the$1...@news.ett.com.ua...
Humm... I do not think that this is legal. Also, I think I read somewhere
that the following is also illegal:
shared.store(1, memory_order_acq_rel);
Why is that?
Dmitriy Vyukov
Store with consumer/acquire/acq_rel ordering is illegal in C++0x, as
well as load with release/acq_rel ordering.
I am not sure how was you able to use it with Relacy, because it
contains following code:
RL_INLINE
void store(T v, memory_order mo, debug_info_param info)
{
assert(memory_order_acquire != mo);
assert(memory_order_acq_rel != mo);
switch (mo)
{
case memory_order_relaxed: return
store_impl<memory_order_relaxed,
&thread_info_base::atomic_store_relaxed>(v, info);
case memory_order_release: return
store_impl<memory_order_release,
&thread_info_base::atomic_store_release>(v, info);
case memory_order_seq_cst: return
store_impl<memory_order_seq_cst,
&thread_info_base::atomic_store_seq_cst>(v, info);
default: break;
}
assert(false);
}
--
Dmitriy V'jukov
Chris M. Thomasson
news:c45cca1b-5202-4905...@m19g2000yqk.googlegroups.com...
On 27 О©╫О©╫О©╫, 14:33, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > What does the following code produce on a SPARC:
> >
> > std::atomic<unsigned> shared;
> >
> > shared.store(1, memory_order_acquire);
> >
> > Is that even a legal operation?
> Store with consumer/acquire/acq_rel ordering is illegal in C++0x, as
> well as load with release/acq_rel ordering.
Okay.That clears my mind; thank you very much.
> I am not sure how was you able to use it with Relacy, because it
> contains following code:
[...]
Unfortunately, the code compiles fine, and runs in debug mode on C++ 2008. I
know that NDEBUG is not defined because I am getting diagnostic output via
the following macro:
#if ! defined (NDEBUG)
# define DBG_PRINTF(mp_exp) std::printf mp_exp
#else
# define DBG_PRINTF(mp_exp) ((void)0)
#endif
What happens when you run the following test code on your end:
http://relacy.pastebin.com/f7d79cd0f
?
Well, it looks like my initial version:
http://relacy.pastebin.com/f2e9297b6
is the way to go; crappy as it is, its still unbounded and intrusive in
nature...
lol. ;^(...
Chris M. Thomasson
news:h291o3$j5$1...@news.ett.com.ua...
> "Dmitriy Vyukov" <dvy...@gmail.com> wrote in message
> news:c45cca1b-5202-4905...@m19g2000yqk.googlegroups.com...
> On 27 О©╫О©╫О©╫, 14:33, "Chris M. Thomasson" <n...@spam.invalid> wrote:
>> > What does the following code produce on a SPARC:
>> >
>> > std::atomic<unsigned> shared;
>> >
>> > shared.store(1, memory_order_acquire);
>> >
>> > Is that even a legal operation?
>
>> Store with consumer/acquire/acq_rel ordering is illegal in C++0x, as
>> well as load with release/acq_rel ordering.
>
> Okay.That clears my mind; thank you very much.
>
>
>
>
>> I am not sure how was you able to use it with Relacy, because it
>> contains following code:
> [...]
>
> Unfortunately, the code compiles fine, and runs in debug mode on C++ 2008.
> I know that NDEBUG is not defined because I am getting diagnostic output
> via the following macro:
>
> #if ! defined (NDEBUG)
> # define DBG_PRINTF(mp_exp) std::printf mp_exp
> #else
> # define DBG_PRINTF(mp_exp) ((void)0)
> #endif
>
>
> What happens when you run the following test code on your end:
>
> http://relacy.pastebin.com/f7d79cd0f
>
> ?
Nevermind. It properly asserts. I screwed up, badly. Stupid, stupid! Dont'
even ask how...
OUCH!
Chris M. Thomasson
Humm... ""Perhaps"" you should move that check form an assertion to an
actual piece of code that will get compiled in release mode...
;^.//////////// My stupid ass moronic retarded bad!!!!!!!!!!!!!!!!!!!!!
I deeply apologize Dmitriy!
;^o
Chris M. Thomasson
> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> news:h29j1r$9bf$1...@news.ett.com.ua...
>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
>> news:h291o3$j5$1...@news.ett.com.ua...
>>> "Dmitriy Vyukov" <dvy...@gmail.com> wrote in message
> I deeply apologize Dmitriy!
Humm... Well, obviously my program fell through select case when NDEBUG is
not defined, but it still passes test on my side. Are you randomly
simulating the effects that the of actual membars have on shared state?
Where am I going wrong? Please educate me!
Anthony Williams
"Chris M. Thomasson" <n...@spam.invalid> writes:
> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> news:h24sf1$the$1...@news.ett.com.ua...
>> std::atomic<unsigned> shared;
>>
>> shared.store(1, memory_order_acquire);
>>
> shared.store(1, memory_order_acq_rel);
These are both illegal under C++0x.
> Why is that?
The C++0x memory model is not described in terms of fences and
barriers. It is described in terms of happens-before relationships. You
can only get such a relationship between threads when one thread reads a
value stored by another, apart from the special case of full sequential
consistency (memory_order_seq_cst).
Since a store doesn't read a value (by definition) it can't be the
"read" end of a write-happens-before-read pairing, so can't have
memory_order_acquire, memory_order_consume or memory_order_acq_rel
ordering.
Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library | http://www.stdthread.co.uk
Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Chris M. Thomasson
news:h24sf1$the$1...@news.ett.com.ua...
wrt Relacy, I was performing most of the testing under Release mode. Perhaps
it might be useful to add custom assertion function instead of using
`assert()' so that they will persist across Debug and Release builds. It
would have caught the boneheaded mistake I made...
;^)