search for: atomic_signal_f

...al, and C allows things in that situation that it disallows for the multi-threaded case. In particular, global objects of type "volatile sig_atomic_t" can be read and written between signal handlers in a thread and that thread's main control flow without locking. C++0x also defines an atomic_signal_fence(memory_order) that only synchronizes with signal handlers, in addition to the atomic_thread_fence(memory_order) that synchronizes to other threads. See [atomics.fences] > I'm not familiar with what synchronization occurs as > part of the interrupt process, but I'd verify it befor...

...n that > situation that it disallows for the multi-threaded case. In > particular, global objects of type "volatile sig_atomic_t" can be read > and written between signal handlers in a thread and that thread's main > control flow without locking. C++0x also defines an > atomic_signal_fence(memory_order) that only synchronizes with signal > handlers, in addition to the atomic_thread_fence(memory_order) that > synchronizes to other threads. See [atomics.fences] Very interesting, and thanks for the clarifications. I'm not particularly familiar with either those parts of C...

On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: > Hi, thanks everyone for all the comments. I think maybe I wasn't clear that > I *only* care about atomicity w.r.t. a signal handler interruption in the > same thread, *not* across threads. Therefore, many of the problems of > cross-CPU atomicity are not relevant. The signal handler gets invoked via

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what