This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

the pthread_once() implementation (bug?)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]