Date: Sun, 4 Feb 2018 23:02:07 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> 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: <20180204210207.GF9536@kib.kiev.ua> In-Reply-To: <20180205064120.K996@besplex.bde.org> 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> <20180205064120.K996@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180204210207.GF9536>