«

Latest C++0x draft N2723, 2008-08-25:
"1.9/7
When the processing of the abstract machine is interrupted by receipt
of a signal, the values of objects which
are neither
— of type volatile std::sig_atomic_t nor
— lock-free atomic objects (29.2)
are unspecified, and the value of any object not in either of these
two categories that is modified by the
handler becomes undefined."

It looks quite strange. Then what atomic_signal_fence() is all about?
Proposal N2731 on bidirectional fences (which includes
atomic_signal_fence()) is not going to change 1.9/7.
I think that proposal on bidirectional fences must also change 1.9/7
to allow usage of plain variables for thread-signal communication
provided that plain variables are properly synchronized with
atomic_signal/thread_fences and/or atomic variables.

Dmitriy V'jukov

"Dmitriy V'jukov" <> writes:

> Latest C++0x draft N2723, 2008-08-25:
> "1.9/7
> When the processing of the abstract machine is interrupted by receipt
> of a signal, the values of objects which
> are neither
> — of type volatile std::sig_atomic_t nor
> — lock-free atomic objects (29.2)
> are unspecified, and the value of any object not in either of these
> two categories that is modified by the
> handler becomes undefined."
>
> It looks quite strange. Then what atomic_signal_fence() is all about?

atomic_signal_fence provides ordering for relaxed atomics and volatile
std::sig_atomic_t variables.

Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

On 9 ÓÅÎÔ, 01:52, Anthony Williams <anthony....@gmail.com> wrote:
> "Dmitriy V'jukov" <dvyu...@gmail.com> writes:
> > Latest C++0x draft N2723, 2008-08-25:
> > "1.9/7
> > When the processing of the abstract machine is interrupted by receipt
> > of a signal, the values of objects which
> > are neither
> > -- of type volatile std::sig_atomic_t nor
> > -- lock-free atomic objects (29.2)
> > are unspecified, and the value of any object not in either of these
> > two categories that is modified by the
> > handler becomes undefined."
>
> > It looks quite strange. Then what atomic_signal_fence() is all about?
>
> atomic_signal_fence provides ordering for relaxed atomics and volatile
> std::sig_atomic_t variables.

Oh! I've missed that moment.

And what about non-relaxed atomics?
Basically I can use following pattern for communication between
threads:
int data;
atomic<int> flag;
void thread1() {
data = 1;
flag.store(1, release);
}
void thread2() {
if (flag.load(acquire))
assert(1 == data);
}

Why I can't use this pattern for thread/signal communication?

Dmitriy V'jukov

"Dmitriy V'jukov" <> writes:

> On 9 �ент, 01:52, Anthony Williams <anthony....@gmail.com> wrote:
>> "Dmitriy V'jukov" <dvyu...@gmail.com> writes:
>> > Latest C++0x draft N2723, 2008-08-25:
>> > "1.9/7
>> > When the processing of the abstract machine is interrupted by receipt
>> > of a signal, the values of objects which
>> > are neither
>> > -- of type volatile std::sig_atomic_t nor
>> > -- lock-free atomic objects (29.2)
>> > are unspecified, and the value of any object not in either of these
>> > two categories that is modified by the
>> > handler becomes undefined."
>>
>> > It looks quite strange. Then what atomic_signal_fence() is all about?
>>
>> atomic_signal_fence provides ordering for relaxed atomics and volatile
>> std::sig_atomic_t variables.
>
> Oh! I've missed that moment.
>
> And what about non-relaxed atomics?
> Basically I can use following pattern for communication between
> threads:
> int data;
> atomic<int> flag;
> void thread1() {
> data = 1;
> flag.store(1, release);
> }
> void thread2() {
> if (flag.load(acquire))
> assert(1 == data);
> }
>
> Why I can't use this pattern for thread/signal communication?

Probably because nobody thought it important enough to write a proposal.

Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL