On Sun, Sep 23, 2012 at 02:43:18PM -0700, Colin McCabe <cmcc...@alumni.cmu.edu> wrote: > If you check the header file, you find that ev_feed_signal_event is > writing to a variable of type EV_ATOMIC_T, which turns out to be a > typedef for sig_atomic_t.
Actually, "volatile sig_atomic_t", unless overriden. The variable likely in question here is, however, an "ev_loop *" - access to these is sufficiently atomic on all platforms we plan to support libev on currently. libev does use memory barriers indeed, but the current release lacks a few - the CVS version should have those fixes. > I think memory barriers have been added to C++11, but they haven't > gotten around to formally adding them to C yet. Actually they are, kind of, in c11. The trouble with them is that they only work for atomics, so are not really classical memory barriers. libecb's code to use these barriers is disabled for that reason. Or maybe I still don't understand them - fences were apparently added very late in the process and don't seem to be as well thought-out as the atomics. > The reality is, volatile is stupid, and most advanced C users use > memory barriers instead. Linus and some other kernel hackers wrote a > document explaining why: > http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt I think volatiles work very well for the case they were defined for. I think the reason many people are so pissed at volatile is that they tried to use it for e.g. threads and after being bitten realised it is indeed dangerously useless :) (Notwithstanding, volatile works for threads in many compilers, for example, microsoft visual c adds memory barriers to volatile accesses, as an extension - maybe this adds to the problem). However, for pre-c11 implementations, threads were of no consequence, and then volatile works just as advertised in a signal handler. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev