[xmlblaster] concurrency problems, double-checked-locking encountered

["Póka Balázs" <p.balazs at gmail.com>]

Hi!

Some weeks ago, I've written about a curiously Very Bad bug which basically caused to client to reconnect so fast to the server, that it would die from resource exhaustion. I've managed to get an idea of what's going on, and I found where the "
XmlBlaster.PingTimer" threads originate from.
Global.java:

   public final Timeout getPingTimer() {
      if (this.pingTimer == null) {
         synchronized(this) {
            if (this.pingTimer == null)
               this.pingTimer = new Timeout("XmlBlaster.PingTimer");
         }
      }
      return this.pingTimer;
   }


And there, I realized how bad it is, because the double-checked-locking idiom is _broken_: 
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
It basically could create any number of theads! (Which, I think, happened for me.)

To be more exact, this type of code can be fixed to run correctly on 1.5+ Sun JVM by declaring the lazily constructed variables volatile. However, it is not implemented on 1.4 (see article), so users of that JVM would still be able to experience a number of interesting things popping up very rarely on their SMP machines.

So, it's particularly bad on SMP machines, which I happen to run the client on.

To make things more interesting, there are at least 15 variables initialized this way in Global.java. I haven't looked anywhere else.

As I have said, it can be fixed by declaring these fields volatile on JVMs I use, but that would mean no solution to some other users.

regards,
Balázs Póka