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

[OndÅej BÃlka <neleai at seznam dot cz>]

On Tue, Mar 26, 2013 at 02:43:47AM -0400, Rich Felker wrote:
> On Tue, Mar 26, 2013 at 01:49:20AM -0300, Alexandre Oliva wrote:
> > I've (not so) recently started working on documenting these safety
> > properties of glibc functions.  I believe now have enough of a patchset
> > to get the discussion on form and content started.
> 
> Wow, nice project.
> 
> > 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.

> > As a result, many functions were marked as unsafe, with âglocaleâ as the
> > reason.  More recently, talking to Carlos about the consequences of this
> > and debating how best to approach the need for some functions to be
> > MT-Safe in spite of setlocale, we decided to document setlocale itself
> > as unsafe, so that calling it after starting threads was documented as
> > problematic.  Then, we could document the fast-path functions as MT-Safe
> > even though they don't bother with locking.
> 
> Per POSIX, setlocale is thread-safe.
>