Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : gniccolai Date : Sat Feb 19 2005 04:48 am gniccolai@yahoo.com (Giancarlo Niccolai) wrote in message news:<95e4efda.0502170320.4b939c22@posting.google.com>... > gottlobfrege@gmail.com wrote in message news:<1108573119.999831.204930@g14g2000cwa.googlegroups.com>... > > Giancarlo Niccolai wrote: > > > > ... > > > as pthread_once does not need > > > to use a mutex, and usually (in well built implementations) it does > > > not. But there are other problems, that I won't discuss with you. > > ... > > > Gian. > > > > Will you discuss it with me? I've been looking at versions of 'once' > > lately (ie boost's and my own) and would be interested in any problems > > with pthread_once, as well as versions that don't use a mutex. (Mine, > > under Windows, appears to only need a Critical Section and a few Atomic > > operations, which, I hope is slightly better than boost's version, > > which uses a global named mutex...) > > > Someone made me notice that: The first call to pthread_once() by any thread in a process, with a given once_control, shall call the init_routine with no arguments. Subsequent calls of pthread_once() with the same once_control shall not call the init_routine. On return from pthread_once(), init_routine shall have completed. The once_control parameter shall determine whether the associated initialization routine has been called. So, (if I read well the fact tha all the pthread_once wait for the completion of init_routine before lending back control to the calling thread) my above sentence is not true. Then the problem remain the same as with the mutexes; pthread_once just atomically initializes some internal mutex, or other blocking thing, but semantically doesn't move our problem of deadlocking code that has been safe by itself before... Gian. .