[omniORB] Static build with GCC 3.4

[Okeefe, Michael K]

On Thursday 03 March 2005 19:43, Visscher, Bruce wrote:
> > I'm not sure. It seems to me that the constructor of a static
> > variable
> > should always be generated and executed,
>
> Unfortunately (IMHO), I don't think it is a simple as that.  I
> seem to recall wording to the effect that the initialization of
> static instances can be deferred until the first use within a
> compilation  unit.  If the instance is never "apparently" used
> then maybe it doesn't have to do it at all.  Side effects don't
> count, so in fact, this breaks some popular design patterns.
>
> It gets worse.  I have recently come to the conclusion that the
> following idiom no longer works for the initialization of
> singletons:
>
> class SingletonLock; // implementation not shown.
>
> class Singleton {
> public:
>   static Singleton& instance() {
>     static Singleton* p=0;
>     if (!p) {
>       SingletonLock lock;
>       if (!p) {
>         static Singleton inst;
>         p=&inst;
>       }
>     }
>     return *p;
>   }
> //...
> };
>

Interesting - I thought this was only a JVM issue:

The "Double-Checked Locking is broken" declaration
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

It seems there is either the same, or at least a very similar issue with
C++:

(Article from Scott Meyers and Andrei Alexandrescu - C++ and the Perils
of Double-Checked Locking )
"Oh, Odysseus, don't let thyself be lured by sirens' voices; for much
trouble is waiting for thou and thy mates!"
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf


> This no longer works not because of compiler optimization but
> because of optimizations that are being performed at the chip
> level.
>
> <soapbox>
> I think the above can be fixed using volatile and/or memory
> barriers and/or by the elimination of the "double check then lock"
> idiom but it was very disturbing to me to learn that something that
> I had determined to be the "proper" way to do something after
> considerable thought and study was now broken by an on-chip
> optimization that doesn't have access to the original source code
> and so knows nothing about sequence points or anything else.
> </soapbox>
> [snip]

There were a few articles (at least for Java) where DCL was a "best
practice".  

Mike