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

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Mar 26, 2013 at 08:20:01AM +0100, OndÅej BÃlka wrote:
> > > One of the stumbling blocks I ran into was that setlocale (unlike
> > > uselocale) may change the global locale object and, even though the
> > > modification of this object is guarded by a rwlock, most uses are not.
> > 
> > I know your work is just documenting existing practice, but unless
> > there's a clause in POSIX (and now, C11 too, since C11 has threads)
> > which allows this, I think the underlying issue should be fixed. The
> > cleanest fix I can envision would be atomically replacing the pointer
> > to the locale object once the new one is prepared. This would
> > eliminate the need for readers to lock anything. If there's a separate
> > pointer for each locale category, readers that depend on more than one
> > category would still need to use a lock to ensure that the entire
> > update is seen atomically (but most readers only use one category).
> > 
> When reader use one category and read it once it is typically safe because 
> setlocale modifies categories atomicaly. Result is nondeterministic but 
> valid as it corresponds to one of serial workloads: fn(); setlocale(); 
> or setlocale(); fn();
> 
> However needs to audit relevant code.

The problem I'm concerned about is that the write might not be visible
even when other synchronizing operations would allow a proof that the
write had already happened. I'm thinking of archs with very loose
memory ordering properties.

Rich