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: Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de>
To: Andrew Johnson <anj@aps.anl.gov>
Date: Thu, 11 Aug 2011 19:57:59 +0200
Hi Andrew

What I would try to avoid at all cost is non-trivial initialization in a
*constructor* for a static object. I listed lazy initialization as one
alternative possibility. Just to make sure we re talking about the same
concept, what I mean is to add some code like

  if (!this->initialized) this->initialize();

at the start of each method. I may be wrong but I can't think of any subsystem
where this approach cannot be used instead of calling initialize() from a
constructor. Remember, when all code in base was written in C we simply did
not *have* the possibility to do anything non-trivial before main (or before
the startup script starts to run); back then there existed exactly the two
ways to solve the problem that I listed: lazy init, or explicit call to init
during startup.

Am Donnerstag, 11. August 2011, um 18:10:55 schrieben Sie:
> 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:

As I said, starting threads lazily is not as evil as doing it directly from a
constructor for a static object, i.e. before main() starts.

> > (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.

I recognize that logging is one of the exceptions to my rule (1) but (again)
we can use lazy initialization here.

> > (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 would like to see the argument that leads to such a conclusion.

> 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.

Of course we would need to make changes to subsystems to make them conform to
stated rules. I would consider this as regular maintenance work, the more so
since the changes needed are mostly mechanical (move the non-trivial stuff from
constructor to extra method, add the code listed above to every method).

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Dr. Ulrich Breuer

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de


Replies:
Re: c++ static initialization Eric Norum
Re: c++ static initialization Andrew Johnson
RE: c++ static initialization Jeff Hill
References:
c++ static initialization Jeff Hill
Re: c++ static initialization Benjamin Franksen
Re: c++ static initialization Andrew Johnson

Navigate by Date:
Prev: Re: c++ static initialization Andrew Johnson
Next: Re: c++ static initialization Eric Norum
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 Andrew Johnson
Next: Re: c++ static initialization Eric Norum
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 ·