Bug 50036 - pthread_once shouldn't return immediately if call in progress
Summary: pthread_once shouldn't return immediately if call in progress
Status: CLOSED WONTFIX
Alias: None
Product: eCos
Classification: Retired
Component: POSIX (EL/IX) (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: ecc-bugs-int
QA Contact: ecc-bugs-int
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-26 07:34 UTC by Jonathan Larmour
Modified: 2007-04-18 16:35 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-20 16:01:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jonathan Larmour 2001-07-26 07:34:21 UTC
From the net:

-=-=-=-=-
The pthread_once() implementation seems have different semantics with the
one in POSIX standard pthread.
(The reference is in page 118 in O'Reilly's book"Pthreads programming" 1st
ed. I assume that the book is correct on this.)

This is the text describing pthread_once() semantics on the book: "No
caller
will exit from pthread_once mechanism until the routine's first caller has
returned."
-=-=-=-=-

which is true. The poster suggested:

-=-=-=-=-
In a word, I think there should be a pair of mutex lock/unlocks around the
invocation of the function pointer passed by user in pthread_once() in
compat/posix/current/src/pthread.cxx to guarantee the correct semantics.
-=-=-=-=-

My reply includes:

-=-=-=-=-
That wouldn't be ideal as _all_ pthread_once's would be serialized. This
would be fatal if the called routine itself called pthread_once. Also we
have to worry about the thread being cancelled in the called routine.
Instead, at a guess, the thing to do is to use the pthread_once_t to record
whether the routine is currently still being processed, and then broadcast
a condition variable to cause it to be checked by any waiting routines that
have called it.
-=-=-=-=-

Comment 1 Alex Schuilenburg 2003-06-20 16:01:29 UTC
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=50036


Note You need to log in before you can comment on or make changes to this bug.