D
Dmitriy V'jukov
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
"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