Re: [ECOS] the pthread_once() implementation (bug?)

[Jonathan Larmour <jlarmour at redhat dot com>]

I-Jui Sung wrote:
> 
> 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."

You are right.
 
> 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.

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.

It's a bit much for me to deal with "for free", so I'm just going to file
it as a bug and leave it for some other time; unless you want to have a go?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/