Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: c++ static initialization
From: "Jeff Hill" <johill@lanl.gov>
To: "'EPICS Core Talk'" <core-talk@aps.anl.gov>
Date: Tue, 9 Aug 2011 14:42:37 -0600
All,

Ref: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14

Of course C++ is really different from C in that some significant code can
run during static initialization. The above FAQ mentions how to avoid some
really serious issues. All of this is pretty common knowledge, but one has
to be careful, and I have definitely seen this bug biting in EPICS base
before. 

However there is still a related issue which should be well understood; not
everyone agrees if threads should be started during C++ static
initialization or not. If multiple threads are running during c++ static
initialization then the solution in the above FAQ doesn?t apply and the only
solution is epicsThreadOnce, but that causes significant runtime overhead
because a lock must be taken and released each time that the epicsThreadOnce
block is checked. I looked in base and I believe that only one thread is
started during static initialization, the win32 time sync PLL, but it is
autonomous and does not interact with anything outside of
osi/os/win32/osdTime.cpp so I think that we are ok - inside of base. What
goes on outside of base, particularly in device drivers, is much less
certain. Note however, that in vxWorks static initialization runs when
iocCore is loaded.

So what is our convention:

Option 1: Don?t start threads from within static initialization. If you do
expect things to break if such threads touch external components.

Option 2: Allow threads to be started during c++ static initialization, but
expect that certain functions will need to increase their overhead by the
cost of one more lock/unlock block because they must embed an
epicsThreadOnce code block in each function that enters into a particular
library.

Opinions?

It would probably be a good idea to clarify our policy in the application
developers guide

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925





Replies:
Re: c++ static initialization Benjamin Franksen

Navigate by Date:
Prev: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill
Next: RE: c++ static initialization Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Andrew Johnson
Next: Re: c++ static initialization Benjamin Franksen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·