On Mon, Feb 05, 2018 at 07:53:03AM +1100, Bruce Evans wrote: > On Sun, 4 Feb 2018, Konstantin Belousov wrote: > > > On Sun, Feb 04, 2018 at 04:15:16PM +1100, Bruce Evans wrote: > >> sig_atomic_t is no better than plain int. This behaviour now makes > >> complete > >> sense. It is just like the undefined behaviour with the ctype functions, > >> except since we own terminate_wfd we can guarantee that it doesn't change > >> while the handler is active (and is valid when the handler is entered). > >> We could also use atomic ops. However, the C standard doesn't require > >> anything that we do to work (except maybe in C11, atomic ops might be > >> explicitly or implicitly specifed to work for things like this). > > > > Atomics are atomic WRT the signal handlers as well, the usual guarantees > > of no torn writes and no out of air values on read hold. Since FreeBSD > > memory model, as documented in atomic(9), claims that naturally aligned > > machine-native integer types are atomic without special declarations on > > access, all guarantees for the handler accesses are already provided. > > C11's precise wording is: > > [for async signals] the behavior is undefined if the signal handler > refers to any object with static or thread storage duration that > is not a lock-free atomic object other than by assigning a value > to an object declared as volatile sig_atomic_t > > i.e., the same as in C99 except the behaviour is not specifically undefined > for accesses to lock-free atomic objects. > > Do we document atomics in userland? C11 atomics are too hard for me. > "lock-free atomic object" is a technical term and I don't know of any > userland documentation that associates this term with naive ideas of > atomics. atomic(9) doesn't mention this either. C11 atomics are not exactly same as FreeBSD atomics, and they are implemented by different API. Our atomic(9) API works same in kernel and in userland.
A (C11) lock-free atomic is the object for which the atomic_is_lock_free() returns true. > > > C11 also has a tool to ensure weaker than usual consistency guarantee, > > only between the thread and a signal handler executing in the context of > > the thread. I do not see it useful in the discussed case. > > Is that just a check for the case if !async signals (ones that are the > result of raise() and abort()?). Probably it was too obscure. I mean atomic_signal_fence(). _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
