Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 18 May 2007 15:32:50 -0500

Hello Kay,

Kay-Uwe Kasemir wrote:

Looks like the onceLock used by epicsThreadOnceOsd() needs to be
initialized by a proper call to epicsThreadInit(), which calls
once(), which performs pthread_mutex_init(&onceLock,0).
Then it's destroyed later from an atExit routine.
Maybe that doesn't happen at the correct time, so the bad status
is the result of a destroyed mutex?

That is my initial guess as to what's happening. However until I've

instrumented the thing better and run it on Fedora-6 I can't be sure.

Maybe one could simply use static initialization of the onceLock, i.e.:

static pthread_mutex_t onceLock = PTHREAD_MUTEX_INITIALIZER;

That way, there's no need to specifically create nor destroy it.

Unfortunately we can't use static initialization because C++ doesn't

guarantee the relative order of initialization of objects in different

translation units that might rely on each other (ISO C++ standard,

section 3.6.2). We found that code in an initializer in one source file

was calling code in another file before the second files' static

initializers had been run, which was causing major problems. That's the

whole purpose of the epicsThreadOnce() stuff that Jeff and Marty had to

put in, to have our own mechanism for initialization that we could control.

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System