Discussion:
[1003.1(2013)/Issue7+TC1 0000874]: pthread_once() rationale makes bogus claims
Austin Group Bug Tracker
2014-09-05 10:31:54 UTC
Permalink
The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=874
======================================================================
Reported By: geoffclare
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 874
Category: System Interfaces
Type: Error
Severity: Comment
Priority: normal
Status: New
Name: Geoff Clare
Organization: The Open Group
User Reference:
Section: pthread_once()
Page Number: 1685
Line Number: 54518
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-09-05 10:31 UTC
Last Modified: 2014-09-05 10:31 UTC
======================================================================
Summary: pthread_once() rationale makes bogus claims
Description:
The following paragraph in the pthread_once() rationale makes bogus claims
about the need for pthread_once():<blockquote>For dynamic library
initialization in a multi-threaded process, a simple initialization flag is
not sufficient; the flag needs to be protected against modification by
multiple threads simultaneously calling into the library. Protecting the
flag requires the use of a mutex; however, mutexes have to be initialized
before they are used. Ensuring that the mutex is only initialized once
requires a recursive solution to this problem.</blockquote>

Ensuring that a mutex is only initialised once does not require a recursive
solution. All it requires is:<pre>pthread_mutex_t mutex =
PTHREAD_MUTEX_INITIALIZER;</pre>

Also, "protecting the flag requires the use of a mutex" is not true, as
there are other ways that the flag could be protected.

In addition, there is a bug in the example code: the initialize_random()
function should have return type void, not int.

Desired Action:
On page 1684 line 54506 section pthread_once()
and page 1685 line 54528 section pthread_once()

In the RATIONALE section, change from:<pre>extern int
initialize_random();</pre>
to:<pre>extern void initialize_random(void);</pre>

On page 1685 line 54518 section pthread_once()

In the RATIONALE section, change from:

For dynamic library initialization in a multi-threaded process, a simple
initialization flag is not sufficient; the flag needs to be protected
against modification by multiple threads simultaneously calling into the
library. Protecting the flag requires the use of a mutex; however, mutexes
have to be initialized before they are used. Ensuring that the mutex is
only initialized once requires a recursive solution to this problem.

The use of <i>pthread_once</i>() not only supplies an
implementation-guaranteed means of dynamic initialization, it provides an
aid to the reliable construction of multi-threaded and realtime systems.
The preceding example then becomes:

to:

For dynamic library initialization in a multi-threaded process, if an
initialization flag is used the flag needs to be protected against
modification by multiple threads simultaneously calling into the library.
This can be done by using a mutex (initialized by assigning
PTHREAD_MUTEX_INITIALIZER). However, the need for a flag can be avoided
altogether by using <i>pthread_once</i>() as follows:
======================================================================

Issue History
Date Modified Username Field Change
======================================================================
2014-09-05 10:31 geoffclare New Issue
2014-09-05 10:31 geoffclare Name => Geoff Clare
2014-09-05 10:31 geoffclare Organization => The Open Group
2014-09-05 10:31 geoffclare Section => pthread_once()
2014-09-05 10:31 geoffclare Page Number => 1685
2014-09-05 10:31 geoffclare Line Number => 54518
2014-09-05 10:31 geoffclare Interp Status => ---
======================================================================
Austin Group Bug Tracker
2014-09-06 13:14:03 UTC
Permalink
A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=874
======================================================================
Reported By: geoffclare
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 874
Category: System Interfaces
Type: Error
Severity: Comment
Priority: normal
Status: New
Name: Geoff Clare
Organization: The Open Group
User Reference:
Section: pthread_once()
Page Number: 1685
Line Number: 54518
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-09-05 10:31 UTC
Last Modified: 2014-09-06 13:14 UTC
======================================================================
Summary: pthread_once() rationale makes bogus claims
======================================================================

----------------------------------------------------------------------
(0002375) dalias (reporter) - 2014-09-06 13:14
http://austingroupbugs.net/view.php?id=874#c2375
----------------------------------------------------------------------
While I agree the current text is imprecise, I'm not sure it's a good idea
to downplay the importance of pthread_once. Using a mutex for dynamic
initialization is highly inappropriate because each lock/unlock operation
synchronizes with every other one, whereas (at least morally; this still
needs to be addressed formally as part of the C11 alignment project)
pthread_once calls synchronize only with completion of the first call.

My personal experience has been that there is still a huge abundance of
dynamic library code performing non-thread-safe initialization (e.g.
requiring the caller to call a library-init function, which does not work
if there are potentially multiple first-callers in a multi-threaded
application). So if anything, I'd like to see the Application Usage and/or
Rationale for pthread_once doing more to encourage proper usage, rather
than just casually offering it as one alternative.

Issue History
Date Modified Username Field Change
======================================================================
2014-09-05 10:31 geoffclare New Issue
2014-09-05 10:31 geoffclare Name => Geoff Clare
2014-09-05 10:31 geoffclare Organization => The Open Group
2014-09-05 10:31 geoffclare Section => pthread_once()
2014-09-05 10:31 geoffclare Page Number => 1685
2014-09-05 10:31 geoffclare Line Number => 54518
2014-09-05 10:31 geoffclare Interp Status => ---
2014-09-06 13:14 dalias Note Added: 0002375
======================================================================
Loading...