2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Mutex error on recent Redhat systems |
From: | Andrew Johnson <[email protected]> |
To: | Kay-Uwe Kasemir <[email protected]> |
Cc: | "'EPICS core-talk'" <[email protected]> |
Date: | 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