[omniORB] Static build with GCC 3.4

[Harri Pasanen]

Ouch, sounds bad.  Can you say which chip you are talking about?

Actually I've noticed similar issues in the code I deal with, and 
subsequently striven towards design where everything 'static' is 
initialized via function call.  Unfortunately it is not always 
possible, especially with third party libs...

-Harri

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;
>   }
> //...
> };
>
> 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>
>
> See the thread "Can C++ local static objects be made thread safe?":
>
> http://groups-beta.google.com/group/comp.programming.threads/browse
>_frm/thread/087f35c382969e7b
>
> Note that the optimzations I refer to are only supposed to affect
> multi-processor machines but I don't believe that.
>
> Bruce
>
> -----------------------------------------
> CONFIDENTIALITY NOTE:  This e-mail message, including any 
> attachment(s), contains information that may be confidential, 
> protected by th attorney-
> client or other legal privileges, and/or  proprietary non-public
> information.  If you are not an intended  recipient of this message
> or an authorized assistant to an intended  recipient, please notify
> the sender by replying to this message and  then delete it from
> your system.  Use, dissemination, distribution,  or reproduction of
> this message and/or any of its attachments (if  any) by unintended
> recipients is not authorized and may be unlawful.
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list


This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.