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  2020  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: c++ static initialization
From: "Jeff Hill" <johill@lanl.gov>
To: "'EPICS Core Talk'" <core-talk@aps.anl.gov>
Date: Tue, 9 Aug 2011 15:03:17 -0600
PPS: We could significantly improve the performance of epicsThreadOnce by
modifying it to use epicsAtomicTestAndSetUInt.

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


> -----Original Message-----
> From: core-talk-bounces@aps.anl.gov [mailto:core-talk-bounces@aps.anl.gov]
> On Behalf Of Jeff Hill
> Sent: Tuesday, August 09, 2011 2:56 PM
> To: 'EPICS Core Talk'
> Subject: RE: c++ static initialization
> 
> PS: My opinion is that the performance impact is actually quite
> significant,
> and therefore we should clearly state our policy that extrovert threads
> should _never_ be started form C++ static initialization. Also if we
> package
> the code in runtime loadable libraries then it's pretty easy to keep these
> issue containerized with each loadable module such as libCom or iocCore,
> and
> if so the policy actually needs to be consistent only for all code within
> a
> single loadable module.
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Jeff Hill [mailto:johill@lanl.gov]
> > Sent: Tuesday, August 09, 2011 2:43 PM
> > To: 'EPICS Core Talk'
> > Subject: c++ static initialization
> >
> > 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
> >
> 




References:
RE: c++ static initialization Jeff Hill

Navigate by Date:
Prev: RE: c++ static initialization Jeff Hill
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  2020 
Navigate by Thread:
Prev: RE: c++ static initialization Jeff Hill
Next: Re: c++ static initialization Hill, Bruce
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020 
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 ·