Re: Thread-, Signal- and Cancellation-safety documentation

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2013-04-04 at 16:04 -0300, Alexandre Oliva wrote:
> On Mar 26, 2013, Rich Felker <dalias@aerifal.cx> wrote:
> > The cleanest fix I can envision would be atomically replacing the
> > pointer to the locale object once the new one is prepared.
> 
> If it was a single pointer, that would indeed be a good course of
> action, but there are multiple pointers that may each change
> independently *or* with a single setlocale call.

Getting atomic snapshots of several memory locations without creating
contention issues in the common case is doable, especially like in this
case when you control the writers and assume that updates are rare
(which I guess is the case for locales, right)?

> Plus, we modify a
> global object, which gets implicitly passed to some functions which read
> from it often without expecting that it might change.

That's where the indirection via the pointers would come into play.  To
update, you'd copy the data pointed to, then use the indirection pointer
to replace it all at once.  Together with some kind of garbage
collection, you then have atomic snapshots for the pointers and whatever
they point to.

> Indeed, besides the ctype functions that don't take a locale object, and
> use the active one (which might be the global locale object), there are
> those that take a pointer to a locale object, and if this object is the
> global locale object, it may change from under them.  Even callers of
> these functions that attempt to read locale properties once as they
> start are toast if they also call any of these interfaces, for then the
> early-reading (presumably for internal consistency) won't guarantee that
> the callees use the same locale information.

And this is exactly an example why saying that "setlocale is
thread-safe" isn't sufficient in terms of the definition.  That's not
your fault; but I believe we need to be more precise here, even if POSIX
isn't.

For example, what you'd get with the atomic snapshots and indirection
approach outlined above doesn't give you the ordering guarantees that
one might expect; it's kind of more like what you'd get from RCU before
quiescence after an update.