Re: Multithreading advice on the manual

[Miguel Ángel Arruga Vivas]

Hi Bruno,

Bruno Haible <bruno@clisp.org> writes:

> In this section I wrote: "The more general solution for initialization
> functions, POSIX pthread_once, is not needed in this case." What is
> wrong about it?
>
>> The multithreaded example contains a race condition
>> (volatile doesn't mean atomic)
>
> This is not a problem.

A data race like this does not mean that the function might be called
more than once, it means that the behaviour of the whole program from
that point on is undefined.  I'm reading the C11 draft (N1570) section
5.1.2.4, point 4 and annex J, section 2 Undefined Behaviour, point 1,
5th bullet.  That includes not being called at all.

In this case, an hypothetical compiler, library and processor
combination may well place the read and the write together (they are
volatile lvalues, not memory fences), and sleep on that thread before
performing the call to bindtextdomain.  Another thread then could read
the stored value and continue without calling bindtextdomain once.

>> and a TOCTOU error even after changing to an atomic variable.
>
> What do you mean by that, exactly? (I have a suspicion, but I prefer
> if you formulate it.)

The TOCTTOU--missing T, Time of check to Time of Use--is not an issue
here, as you has pointed out, because the function called is idempotent.

> Unfortunately, this approach has two problems:
>
>   * call_once has a lot of portability problems [2]. pthread_once has
>     fewer portability problems [3], but still. The effect is that only
>     packages that rely on Gnulib could use the code snippet. However,
>     the gettext manual targets package of any license (since glibc and
>     libintl are under LGPL).

Great point, a older systems don't have a C11 toolchain and library
handy.

>   * Using call_once or pthread_once has link requirements, see [4][5].
>     So, it has a globally visible effect on the library.

I have mixed feelings here, as a library prepared for multithreading
usually have mechanisms for that case in place, but point your point is
clear.

After gathering this information, what do you think of changing volatile
to _Atomic?  It won't produce ill-formed programs now, not by 2030.
bindtextdomain might be called more than once, but it's ensured that it
will be called before the first library call to dcgettext.

Best regards,
Miguel

0001-Update-manual-advice-on-multiple-threads.patch
Description: _Atomic instead of volatile