[omniORB] Static build with GCC 3.4

Visscher, Bruce VISSCHB at RJRT.com
Thu Mar 3 13:43:59 GMT 2005


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




More information about the omniORB-list mailing list