Question: I've got a problem where I generated a Quicktime plgin using the AC\_Quicktime plugin, and then drop this into a using jquery. In Firefox I can then reference the created plugin using it's objectid, but in IE 6.0 this doesn't seem to work.

I've tried using jquery to reference the plugin... but can't seem to do so.

Here's the code that generates the plugin parameters:-

```
var movie1 = QT_GenerateOBJECTText(
        currentfile, playerwidth, playerheight, "",
        "controller","false",
        "obj#id", "movie1",
        "emb#id","qt_movie1",
        "postdomevents","True",
        "emb#NAME","movie1",
            "enablejavascript","true",
        "autoplay",boolplaying,
        "scale","aspect",
        "pluginspage","http://www.apple.com/quicktime/download/"
            );

            $("#player").html(movie1);

```

I then check that the plugin has been generated using this, and then do some stuff with it:-

```
if ($("#qt_movie1").length > 0)
            {
              alert('clip loaded up');
            //clip with embedded id 'qt_movie1' must be loaded so wait a bit then run timecode()
            //showEvents('now run timecode');

            //calculate duration
            Id = window.setTimeout("timecode()",500);
            }

```

In Firefox the alert (for debug purposes) fires off but it doesn't in IE. In another simple function I stop the movie using this:-

```
function stopmovie()
{

  document.movie1.Stop();
  boolplaying = false;

}

```

Again 'document.movie1' works to reference the movie in Firefox, but not IE.

Is there a jquery selector I can use for the quicktime plugin? Or is there another way to reference the plugin?

Cheers.

Jon

Answer: 
Assuming Java 5 or later then declaring it volatile gives well-defined semantics as desscribed [here](http://www.javamex.com/tutorials/synchronization_volatile.shtml). On the principle of removing doubt from the code maintainer's mind I would use volatile, saying "yes I know that multiple threads use this variable".

The intersting question is the effect of not declaring it volatile. Provided that you got **a** prime, does it matter if it's the very latest available? Volatile ensures taht values are taken from memory, not any "CPU" caches, so you should get a more up to date value. 

What about the possibility of seeing a partial assigment? Could you get really unlucky and see a long whose LSBs are part of an old value and MSBs part of a different value? Well, assignments to longs and doubles are not atomic, so in theory yes!

Ergo, volatile or synchronized is not just a nice-to-have ... you need it
Semantics of volatile variable in Java are not strong enough to make the increment operation (lastprime++) atomic, unless you can guarantee that the variable is written only from a single thread - not in servlet's case

On the other hand, using AtomicXXX variables is thread-safe, as long as no compounded operations are performed. There will be window of vulnerability when updating more than one atomic variables, even though each call to is atomic.