This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Rich Felker <dalias at aerifal dot cx>
- To: libc-alpha at sourceware dot org
- Date: Tue, 26 Mar 2013 18:49:07 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <20130326072001 dot GA7671 at domone dot kolej dot mff dot cuni dot cz>
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