This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
the pthread_once() implementation (bug?)
- To: "eCos mailing list" <ecos-discuss at sources dot redhat dot com>
- Subject: [ECOS] the pthread_once() implementation (bug?)
- From: "I-Jui Sung" <ijsung at csie dot nctu dot edu dot tw>
- Date: Tue, 24 Jul 2001 05:25:28 +0800
Hi, folks:
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."
In order to verify the pthread_once() semantics of eCos pthread
implementation, I wrote a small program (see attachment) to do it.
Basically it creates 2 threads, and of course both of them invoke
pthread_once(). The initialization routine simply sleeps for 10 ticks.
However the result was not the same as I think, because the 2nd caller
immediately returns while the 1st caller still blocks in
pthread_once!
(Here I assume the second caller of pthread_once() will also block in
pthread_once() until the 1st caller returns from it, which is correct (I
think) semantics of the pthread_once().)
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.
Best,
I-Jui Sung
pthread_test.c