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: Andrew Johnson <anj@aps.anl.gov>
To: core-talk@aps.anl.gov
Date: Thu, 11 Aug 2011 11:10:55 -0500
Hi Benjamin,

On 2011-08-09 Benjamin Franksen wrote:
> (1) Static objects should be avoided wherever possible.
> 
> (2) If static objects are used, the constructor should be trivial, i.e. not
> perform anything except setting members to default values.

We can't enforce that as a hard rule — Eric's example of registering iocsh 
commands is one, and there are others.  Maybe we need to document which EPICS 
APIs /can/ be used in static initialization code and which /can't/.

On vxWorks and some RTEMS systems the NTPTimeSync and ClockTimeSync threads 
are started from a static initializer, and they also get registered with the 
taskwd subsystem which lazily starts its own thread as a result:

mv6100> ld 0,0, "test.munch"
value = 515189984 = 0x1eb52ce0
mv6100> i
  NAME        ENTRY       TID    PRI   STATUS    PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- ------ -------- ------- -----
tExcTask   excTask      1effcc30   0 PEND       1e9b18 1effcb10   3006b     0
tLogTask   logTask      1effa060   0 PEND       1e9b18 1eff9f50       0     0
tShell     shell        1edbf600   1 READY      1e368c 1edbf200  8800dd     0
tNetTask   netTask      1ef70c40  50 PEND       1dddc0 1ef70b50       0     0
NTPTimeSync1eaf5a54     1eb51730 109 PEND+T     1dddc0 1eb515a0       0  3404
ClockTimeSy1eaf5a54     1eb4f1d0 109 PEND+T     1dddc0 1eb4f050       0  3400
taskwd     1eaf5a54     1edc9d30 189 PEND+T     1dddc0 1edc9bb0       0   155
value = 0 = 0x0


> (3) Non-trivial initialization for complex objects should be done in a
>  regular method either lazily ("Construct On First Use") or by an explicit
>  call from some startup routine. The latter has the advantage of a
>  well-defined order of initialization; the former is sometimes more
>  convenient.

There is a major thicket here which needs careful examination...

> (4) Starting threads inside static initialization is a bad idea and should
>  not be allowed (see rule 2).

I agree that in principle we shouldn't allow calls to epicsThreadCreate() from 
static constructors, but we already have several examples above which can't 
easily be changed, and anything that calls an errlog routine from a static 
constructor will lazily start the errlog thread for some more.

> (5) epicsThreadOnce should also be avoided wherever possible. Using it
>  means objects cannot be freely passed between threads which is detriment
>  to composability.

But as Jeff implied, epicsThreadOnce() is essential to coding lazy 
initialization correctly on an SMP system.

I don't know what the best solution is to all this, but I do know that we 
can't just write down a set of rules without examining all our subsystems and 
making changes to bring them into compliance.

I would definitely favor improving the performance of epicsThreadOnce() for 
those subsystems that currently use lazy initialization though.

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham


Replies:
Re: c++ static initialization Benjamin Franksen
References:
c++ static initialization Jeff Hill
Re: c++ static initialization Benjamin Franksen

Navigate by Date:
Prev: Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base 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 Eric Norum
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 
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 ·