Am Donnerstag, 11. August 2011, um 21:58:55 schrieb Andrew Johnson:
> On 2011-08-11 you wrote:
> > if (!this->initialized) this->initialize();
>
> Your code above is not SMP-safe, and actually it's not even safe on a UP
> system in some circumstances. If there are at least two threads running
> then they can both execute the initialize() method simultaneously (before
> the other thread sets the initialized member), which is obviously a Bad
> Thing™. You can't even protect the initialize() routine with its own
> mutex because someone has to create the mutex for the routine to lock.
> The epicsThreadOnce() routine was designed to solve exactly this problem,
> and I believe we have already converted all the code in Base to use it.
> The result looks like this:
>
>
> static epicsThreadOnceId onceId = EPICS_THREAD_ONCE_INIT;
>
> static void once(void *junk)
> { ... }
>
> FILE * epicsShareAPI doSomething(...)
> {
> epicsThreadOnce(&onceId, once, 0);
> ...
> }
Right. I confused epicsThreadOnce with thread local storage (such as, for
instance, used in the CA client API to store the current client context).
Sorry for the confusion.
I was actually aware of the problem; I took great care in the sequencer to
minimize the use of global variables and where I could not avoid them I
banished initialization (particularly: initialization of a global lock to
protect them) to the phase where the iocsh functions get registered (assuming
that no multitasking is active when this happens). Would this approach would
work for other subsystems?
> > > > (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.
>
> http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
Thanks for the link. The paper confirms my opinion that singletons (static
objects, whatever) should be avoided whenever possible. They just cause
endless subtle problems.
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
- 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 Jeff Hill
- Next:
c++ 0x initialization of local (block scoped) static variables Jeff Hill
- 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 Jeff Hill
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|