Double checked locking pattern article on aristeia

There is something in this article that puzzles me
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

The article says the following code may not work correctly in a
multi-threaded environment for two reasons. The code has volatile all
over the place to prevent the compiler from re-ordering code. The
idea is to avoid acquiring the (expensive) Lock every time you need to
access the singleton.

class Singleton {
public:
  static volatile Singleton* volatile instance();
  //...
private:
//
  static volatile Singleton* volatile pInstance;
};

// from the implementation file
volatile Singleton* volatile Singleton::pInstance = 0;

volatile Singleton* volatile Singleton::instance() {
  if (pInstance == 0) {
     Lock lock;
     if (pInstance == 0) {
        volatile Singleton* volatile temp =
              new volatile Singleton;
        pInstance = temp;
     }
  }
  return pInstance;
}

The first reason given for why this code may fail in a multi-threaded
environment is given on page 10
<quote>
First, the Standard?s constraints on observable behavior are only for
an abstract machine defined by the Standard, and that abstract machine
has no notion of multiple threads of execution. As a result, though
the Standard prevents compilers from reordering reads and writes to
volatile data within a thread, it imposes no constraints at all on
such reorderings across threads. At least that?s how most compiler
implementers interpret things. As a result, in practice, many
compilers may generate thread-unsafe code from the source above.
<end quote>

I can't figure out what the above quoted text is getting at. Can
anyone explain? What does "re-ordering across threads" mean?

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]