Re: Library initialization with gettext is not thread-safe

[Bruno Haible]

Vivien Kraus wrote:
> I may be wrong, but I think that reading libfoo_initialized (in
> create_foo) while another thread is modifying it (in libfoo_initialize)
> is undefined behavior, even for a bool.

Ah right. On some CPU types (e.g. IA64), the value is not propagated
between caches of different CPUs, unless the compiler arranges for it.
To tell the compiler to do so, either a 'volatile' marker or an
'atomic' type is needed (like you say).

> Having thought about it a bit more, I have found 2 solution:
> - Use an atomic variable for libfoo_initialized;
> - Use pthread_once.

You're right, both are proper solutions.

> However, atomic variables are quite a recent addition to C so I’m not
> sure it can be advertised in the manual.

Yes, atomics are still not fully portable in practice.

> And I don’t know much about pthread_once,

pthread_once would guarantee that the initialization function gets called
only once. But it is overkill here.

> I don’t know whether it works if create_foo is called
> from competing threads from different threading libraries (such as 2
> openmp threads for instance).

OpenMP threads are based on libc threads, which means POSIX threads on
Linux or Windows threads on Windows. So, from the perspective of
pthread_once, there is no difference between a main thread, a thread created
by pthread_create, or an OpenMP thread.

I've added this doc improvement:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=211cb6b979e75793387ca44d1343e5233570d534

Thanks for your good report!

Bruno