[EMAIL PROTECTED] wrote:
>
> Marc, I don't entirely understand what you have pointed out here. It sounds
>important, but I have to admit I don't get it.
> Do you mean to say that, for proper synchronization, we must synchronize the whole
>getInstance method? I would think that if
> another thread tried to access any of the class's fields, it would either be blocked
>at the synchronized block (if it was in
> process of obtaining a reference for the first time), or it would already have a
>valid reference to the singleton, in which
> case why would the fields be bogus?
>
> And how can a thread pre-read contents of an object, if it has yet to obtain a bona
>fide instance of it?
>
> I am still finding my thread sea legs, so to speak, so apologies for being so blind
>to this.
>
> -Armen
>
> > On Wed, 13 Oct 1999, Peter Pilgrim wrote:
> >
> > > Or perhaps alternatively the lazy singleton.
> > >
> > > public class NetworkPrinter {
> > >
> > > protected PaperStack paper
> > > protected static Object locker = new Object();
> > > private static NetworkPrinter thePrinter = null;
> > >
> > >
> > > private NetworkPrinter ( )
> > > {
> > > }
> > >
> > > public static NetworkPrinter getInstance()
> > > {
> > > if ( thePrinter != null ) {
> > > // Thread Safety - Double Guard technique
> > > synchronized( locker )
> > > if ( thePrinter != null ) {
> > > thePrinter = new NetworkPrinter();
> > > }
> > > }
> > > return (thePrinter);
> >
> > (yea, this is somewhat offtopic, but...)
> >
> > This is not properly synchronized, as I have been taught by someone with
> > more sense than I have.
> >
> > The basic problem revolves around the fact that synchronization is
> > not just for serialization but is also for visibility. ie. without
> > synchronization, you are not always guaranteed that a change made by
> > one thread is visible in another. Sometimes this is ok.
> >
> > Although the JLS guarantees that the thePrinter reference must be
> > fully visible if it is visible, it doesn't guarantee that instance
> > variables, etc. of the class that thePrinter references are also
> > visible. So if the creating thread is still in the synchronized
> > block, then the value stored in thePrinter may be copied to main
> > memory, but things like instance variables may not be, so when
> > another thread tries to use them they are bogus.
> >
> > In addition, apparently another thread could have pre-read the contents
> > of the object referenced by thePrinter before it reads the reference
> > in thePrinter.
> >
> > What it boils down to is you can't cheat on synchronization.
> >
In fact code is wrong, at least in the conditionals statements.
Sorry about that
public static NetworkPrinter getInstance()
{
// Point *A*
if ( thePrinter == null ) {
// Thread Safety - Double Guard technique
// Point *B*
synchronized( locker ) {
// Point *C*
// SHOULD BE A CRITICAL SECTION
if ( thePrinter == null ) {
thePrinter = new NetworkPrinter();
}
}
return (thePrinter);
}
I can't understand what is the problem with the double guard technique.
You synchronize threads on the `locker' object and that should be
enough. In fact it should act like a `Mutex' (mutual exclusion).
If you have two threads t1 and t2 racing to create the singleton
which is not yet inited yet at Point A, both will get to Point B.
However only one of the two threads, assume by random choice t2,
will get to Point C, because of the use of the synchronized object
`locker'. Thread t2 will be allowed access to the critical section,
and t1 will be blocked until t2 leaves the critical section.
t2 will create the singleton and return it to its calling
thread. As it leaves the monitor `locker' it will unblock t1
from waiting, t1 will enter the critical section, and
discovers that the singleton `thePrinter' already exists.
It therefore returns the same singleton that t2 created.
So converning invisiblity and visibility what's the problem?
--
Adios
Peter
-----------------------------------------------------------------
import std.Disclaimer; // More Java for your Lava, Mate.
"Give the man, what he wants. £££" [on Roy Keane, Quality Player]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
