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-head@freebsd.org mailing list
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to