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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|