Date: Mon, 5 Feb 2018 07:53:03 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Conrad Meyer <cem@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327495 - head/usr.sbin/rpcbind Message-ID: <20180205064120.K996@besplex.bde.org> In-Reply-To: <20180204103334.GC9536@kib.kiev.ua> References: <201801021725.w02HPDaj068477@repo.freebsd.org> <20180203232725.U1389@besplex.bde.org> <CAG6CVpXodjf7HfagpaY6K1t69a1jx37FRqvQq2acg5eT0r1Z-A@mail.gmail.com> <20180204150751.V909@besplex.bde.org> <20180204103334.GC9536@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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()?).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180205064120.K996>