Thread safe or not ?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Thread safe or not ?

Hanson Char
Assuming JDK5, is the following code always thread safe when SystemParameter.K is concurrently accessed  ?  If so, is the synchronization used in the code minimal ?  If not, why not ?

Thanks in advance.

Hanson

public class SystemParameter {
    private static volatile SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Thread safe or not ?

David Holmes
Hanson,
 
SystemParameter.K is a static final long value that is initialized during static initialization from a newly constructed - and hence otherwise inaccessible - object. So as it stands it is always threadsafe to access it, as static initialization is itself threadsafe.
 
I don't know why the bean variable is volatile if it is only accessed during static initialization. So it may not be minimal synchronization.
 
However the comment:
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
is not correct. If you use an externally configured bean object to initialize K then you need to be guaranteed that that beans k field has been correctly set and may not be concurrently set while being read from getK. As these are long values then atomicity of reads/writes does not apply and you may read a garbage value.
 
Hope that helps.
 
David Holmes
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Friday, 23 September 2005 3:19 PM
To: [hidden email]
Subject: [concurrency-interest] Thread safe or not ?

Assuming JDK5, is the following code always thread safe when SystemParameter.K is concurrently accessed  ?  If so, is the synchronization used in the code minimal ?  If not, why not ?

Thanks in advance.

Hanson

public class SystemParameter {
    private static volatile SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Hanson Char
I see, so the amended code below is both thread-safe and minimal, and hopefully with the correct comment.

Hanson

public class SystemParameter {
    private static SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance, as long as such
        // instance is constructed and accessed by only 1 thread
        // (ie not concurrently.)
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}



On 9/23/05, David Holmes <[hidden email]> wrote:
Hanson,
 
SystemParameter.K is a static final long value that is initialized during static initialization from a newly constructed - and hence otherwise inaccessible - object. So as it stands it is always threadsafe to access it, as static initialization is itself threadsafe.
 
I don't know why the bean variable is volatile if it is only accessed during static initialization. So it may not be minimal synchronization.
 
However the comment:
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
is not correct. If you use an externally configured bean object to initialize K then you need to be guaranteed that that beans k field has been correctly set and may not be concurrently set while being read from getK. As these are long values then atomicity of reads/writes does not apply and you may read a garbage value.
 
Hope that helps.
 
David Holmes
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Friday, 23 September 2005 3:19 PM
To: [hidden email]
Subject: [concurrency-interest] Thread safe or not ?

Assuming JDK5, is the following code always thread safe when SystemParameter.K is concurrently accessed  ?  If so, is the synchronization used in the code minimal ?  If not, why not ?

Thanks in advance.

Hanson

public class SystemParameter {
    private static volatile SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Hanson Char
Or more generally,
...
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance, as long as such
        // instance is constructed and accessed in a thread safe manner.
...

Hanson

On 9/23/05, Hanson Char <[hidden email]> wrote:
I see, so the amended code below is both thread-safe and minimal, and hopefully with the correct comment.

Hanson

public class SystemParameter {
    private static SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance, as long as such
        // instance is constructed and accessed by only 1 thread
        // (ie not concurrently.)
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}



On 9/23/05, David Holmes <[hidden email]> wrote:
Hanson,
 
SystemParameter.K is a static final long value that is initialized during static initialization from a newly constructed - and hence otherwise inaccessible - object. So as it stands it is always threadsafe to access it, as static initialization is itself threadsafe.
 
I don't know why the bean variable is volatile if it is only accessed during static initialization. So it may not be minimal synchronization.
 
However the comment:
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
is not correct. If you use an externally configured bean object to initialize K then you need to be guaranteed that that beans k field has been correctly set and may not be concurrently set while being read from getK. As these are long values then atomicity of reads/writes does not apply and you may read a garbage value.
 
Hope that helps.
 
David Holmes
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Friday, 23 September 2005 3:19 PM
To: [hidden email]
Subject: [concurrency-interest] Thread safe or not ?

Assuming JDK5, is the following code always thread safe when SystemParameter.K is concurrently accessed  ?  If so, is the synchronization used in the code minimal ?  If not, why not ?

Thanks in advance.

Hanson

public class SystemParameter {
    private static volatile SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Joe Bowbeer
In reply to this post by Hanson Char
I guess I'm missing the point but GC hints always make me suspicious.

Can you assign K in the static initializer?  That would be more streamlined:

public class SystemParameter {
    public static final long K;
    static {
        SystemParameterBean bean = init();
        K = bean.getK();
    }
    // ...

On 9/22/05, Hanson Char <[hidden email]> wrote:

> I see, so the amended code below is both thread-safe and minimal, and
> hopefully with the correct comment.
>
>  Hanson
>
>  public class SystemParameter {
>      private static SystemParameterBean bean = init();
>      public static final long K = bean.getK();
>      static {
>          bean = null;    // hint to GC
>      }
>      private static SystemParameterBean init() {
>          // This part can be replaced by accessing an IoC framework
>          // such as Spring to retrieve an externally configured
>          // SystemParameterBean instance, as long as such
>          // instance is constructed and accessed by only 1 thread
>          // (ie not concurrently.)
>          SystemParameterBean bean = new SystemParameterBean();
>          bean.setK(20);
>          return bean;
>      }
>  }
>
>  public class SystemParameterBean {
>      private long k;
>
>      public long getK() {
>          return k;
>      }
>      public void setK(long k) {
>          this.k = k;
>      }
>  }
>
>
> On 9/23/05, David Holmes <[hidden email]> wrote:
> >
> > Hanson,
> >
> > SystemParameter.K is a static final long value that is initialized during
> static initialization from a newly constructed - and hence otherwise
> inaccessible - object. So as it stands it is always threadsafe to access it,
> as static initialization is itself threadsafe.
> >
> > I don't know why the bean variable is volatile if it is only accessed
> during static initialization. So it may not be minimal synchronization.
> >
> > However the comment:
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >
> > is not correct. If you use an externally configured bean object to
> initialize K then you need to be guaranteed that that beans k field has been
> correctly set and may not be concurrently set while being read from getK. As
> these are long values then atomicity of reads/writes does not apply and you
> may read a garbage value.
> >
> > Hope that helps.
> >
> > David Holmes
> >
> >
> >
> > -----Original Message-----
> > From: [hidden email]
> [mailto:[hidden email]]On
> Behalf Of Hanson Char
> > Sent: Friday, 23 September 2005 3:19 PM
> > To: [hidden email]
> > Subject: [concurrency-interest] Thread safe or not ?
> >
> > Assuming JDK5, is the following code always thread safe when
> SystemParameter.K is concurrently accessed  ?  If so, is the synchronization
> used in the code minimal ?  If not, why not ?
> >
> > Thanks in advance.
> >
> > Hanson
> >
> > public class SystemParameter {
> >     private static volatile SystemParameterBean bean = init();
> >     public static final long K = bean.getK();
> >     static {
> >         bean = null;    // hint to GC
> >     }
> >     private static SystemParameterBean init() {
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >         SystemParameterBean bean = new SystemParameterBean();
> >         bean.setK(20);
> >         return bean;
> >     }
> > }
> >
> > public class SystemParameterBean {
> >     private long k;
> >
> >     public long getK() {
> >         return k;
> >     }
> >     public void setK(long k) {
> >         this.k = k;
> >     }
> > }
> >
> >
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Hanson Char
I agree.  That's more streamlined.  Thanks!

Hanson

On 9/23/05, Joe Bowbeer <[hidden email]> wrote:
I guess I'm missing the point but GC hints always make me suspicious.

Can you assign K in the static initializer?  That would be more streamlined:

public class SystemParameter {
    public static final long K;
    static {
        SystemParameterBean bean = init();
        K = bean.getK();
    }
    // ...

On 9/22/05, Hanson Char <[hidden email]> wrote:

> I see, so the amended code below is both thread-safe and minimal, and
> hopefully with the correct comment.
>
>  Hanson
>
>  public class SystemParameter {
>      private static SystemParameterBean bean = init();
>      public static final long K = bean.getK();
>      static {
>          bean = null;    // hint to GC
>      }
>      private static SystemParameterBean init() {
>          // This part can be replaced by accessing an IoC framework
>          // such as Spring to retrieve an externally configured
>          // SystemParameterBean instance, as long as such
>          // instance is constructed and accessed by only 1 thread
>          // (ie not concurrently.)
>          SystemParameterBean bean = new SystemParameterBean();
>          bean.setK(20);
>          return bean;
>      }
>  }
>
>  public class SystemParameterBean {
>      private long k;
>
>      public long getK() {
>          return k;
>      }
>      public void setK(long k) {
>          this.k = k;
>      }
>  }
>
>
> On 9/23/05, David Holmes < [hidden email]> wrote:
> >
> > Hanson,
> >
> > SystemParameter.K is a static final long value that is initialized during
> static initialization from a newly constructed - and hence otherwise
> inaccessible - object. So as it stands it is always threadsafe to access it,
> as static initialization is itself threadsafe.
> >
> > I don't know why the bean variable is volatile if it is only accessed
> during static initialization. So it may not be minimal synchronization.
> >
> > However the comment:
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >
> > is not correct. If you use an externally configured bean object to
> initialize K then you need to be guaranteed that that beans k field has been
> correctly set and may not be concurrently set while being read from getK. As
> these are long values then atomicity of reads/writes does not apply and you
> may read a garbage value.
> >
> > Hope that helps.
> >
> > David Holmes
> >
> >
> >
> > -----Original Message-----
> > From: [hidden email]
> [mailto:[hidden email]]On
> Behalf Of Hanson Char
> > Sent: Friday, 23 September 2005 3:19 PM
> > To: [hidden email]
> > Subject: [concurrency-interest] Thread safe or not ?
> >
> > Assuming JDK5, is the following code always thread safe when
> SystemParameter.K is concurrently accessed  ?  If so, is the synchronization
> used in the code minimal ?  If not, why not ?
> >
> > Thanks in advance.
> >
> > Hanson
> >

> > public class SystemParameter {
> >     private static volatile SystemParameterBean bean = init();
> >     public static final long K = bean.getK();
> >     static {
> >         bean = null;    // hint to GC
> >     }
> >     private static SystemParameterBean init() {
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >         SystemParameterBean bean = new SystemParameterBean();
> >         bean.setK(20);
> >         return bean;
> >     }
> > }

> >
> > public class SystemParameterBean {
> >     private long k;
> >
> >     public long getK() {
> >         return k;
> >     }
> >     public void setK(long k) {
> >         this.k = k;
> >     }
> > }
> >
> >
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Thread safe or not ?

David Holmes
In reply to this post by Hanson Char
Right.
 
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Friday, 23 September 2005 4:08 PM
To: David Holmes
Cc: [hidden email]
Subject: Re: [concurrency-interest] Thread safe or not ?

Or more generally,
...
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance, as long as such
        // instance is constructed and accessed in a thread safe manner.
...

Hanson

On 9/23/05, Hanson Char <[hidden email]> wrote:
I see, so the amended code below is both thread-safe and minimal, and hopefully with the correct comment.

Hanson

public class SystemParameter {
    private static SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance, as long as such
        // instance is constructed and accessed by only 1 thread
        // (ie not concurrently.)
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}



On 9/23/05, David Holmes <[hidden email]> wrote:
Hanson,
 
SystemParameter.K is a static final long value that is initialized during static initialization from a newly constructed - and hence otherwise inaccessible - object. So as it stands it is always threadsafe to access it, as static initialization is itself threadsafe.
 
I don't know why the bean variable is volatile if it is only accessed during static initialization. So it may not be minimal synchronization.
 
However the comment:
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
is not correct. If you use an externally configured bean object to initialize K then you need to be guaranteed that that beans k field has been correctly set and may not be concurrently set while being read from getK. As these are long values then atomicity of reads/writes does not apply and you may read a garbage value.
 
Hope that helps.
 
David Holmes
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Friday, 23 September 2005 3:19 PM
To: [hidden email]
Subject: [concurrency-interest] Thread safe or not ?

Assuming JDK5, is the following code always thread safe when SystemParameter.K is concurrently accessed  ?  If so, is the synchronization used in the code minimal ?  If not, why not ?

Thanks in advance.

Hanson

public class SystemParameter {
    private static volatile SystemParameterBean bean = init();
    public static final long K = bean.getK();
    static {
        bean = null;    // hint to GC
    }
    private static SystemParameterBean init() {
        // This part can be replaced by accessing an IoC framework
        // such as Spring to retrieve an externally configured
        // SystemParameterBean instance.
        SystemParameterBean bean = new SystemParameterBean();
        bean.setK(20);
        return bean;
    }
}

public class SystemParameterBean {
    private long k;

    public long getK() {
        return k;
    }
    public void setK(long k) {
        this.k = k;
    }
}




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Thread safe or not ?

David Holmes
In reply to this post by Hanson Char
I had presumed the code was an outline of something more elaborate and it was the "pattern" of initialization that was significant - otherwise it can be reduced to:
 
public static final long K = 20;
 
or if obtained from the "external" bean:
 
public static final long K = getExternalBean().getK();
 
there's no need to keep a reference to the bean. :)
 
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Friday, 23 September 2005 5:24 PM
To: Joe Bowbeer
Cc: [hidden email]
Subject: Re: [concurrency-interest] Thread safe or not ?

I agree.  That's more streamlined.  Thanks!

Hanson

On 9/23/05, Joe Bowbeer <[hidden email]> wrote:
I guess I'm missing the point but GC hints always make me suspicious.

Can you assign K in the static initializer?  That would be more streamlined:

public class SystemParameter {
    public static final long K;
    static {
        SystemParameterBean bean = init();
        K = bean.getK();
    }
    // ...

On 9/22/05, Hanson Char <[hidden email]> wrote:

> I see, so the amended code below is both thread-safe and minimal, and
> hopefully with the correct comment.
>
>  Hanson
>
>  public class SystemParameter {
>      private static SystemParameterBean bean = init();
>      public static final long K = bean.getK();
>      static {
>          bean = null;    // hint to GC
>      }
>      private static SystemParameterBean init() {
>          // This part can be replaced by accessing an IoC framework
>          // such as Spring to retrieve an externally configured
>          // SystemParameterBean instance, as long as such
>          // instance is constructed and accessed by only 1 thread
>          // (ie not concurrently.)
>          SystemParameterBean bean = new SystemParameterBean();
>          bean.setK(20);
>          return bean;
>      }
>  }
>
>  public class SystemParameterBean {
>      private long k;
>
>      public long getK() {
>          return k;
>      }
>      public void setK(long k) {
>          this.k = k;
>      }
>  }
>
>
> On 9/23/05, David Holmes < [hidden email]> wrote:
> >
> > Hanson,
> >
> > SystemParameter.K is a static final long value that is initialized during
> static initialization from a newly constructed - and hence otherwise
> inaccessible - object. So as it stands it is always threadsafe to access it,
> as static initialization is itself threadsafe.
> >
> > I don't know why the bean variable is volatile if it is only accessed
> during static initialization. So it may not be minimal synchronization.
> >
> > However the comment:
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >
> > is not correct. If you use an externally configured bean object to
> initialize K then you need to be guaranteed that that beans k field has been
> correctly set and may not be concurrently set while being read from getK. As
> these are long values then atomicity of reads/writes does not apply and you
> may read a garbage value.
> >
> > Hope that helps.
> >
> > David Holmes
> >
> >
> >
> > -----Original Message-----
> > From: [hidden email]
> [mailto:[hidden email]]On
> Behalf Of Hanson Char
> > Sent: Friday, 23 September 2005 3:19 PM
> > To: [hidden email]
> > Subject: [concurrency-interest] Thread safe or not ?
> >
> > Assuming JDK5, is the following code always thread safe when
> SystemParameter.K is concurrently accessed  ?  If so, is the synchronization
> used in the code minimal ?  If not, why not ?
> >
> > Thanks in advance.
> >
> > Hanson
> >
> > public class SystemParameter {
> >     private static volatile SystemParameterBean bean = init();
> >     public static final long K = bean.getK();
> >     static {
> >         bean = null;    // hint to GC
> >     }
> >     private static SystemParameterBean init() {
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >         SystemParameterBean bean = new SystemParameterBean();
> >         bean.setK(20);
> >         return bean;
> >     }
> > }
> >
> > public class SystemParameterBean {
> >     private long k;
> >
> >     public long getK() {
> >         return k;
> >     }
> >     public void setK(long k) {
> >         this.k = k;
> >     }
> > }
> >
> >
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Hanson Char
That's exactly right - very astute observation as usual.  It's an outline of a pattern for initializing, in a thread-safe manner, multiple final static constants via (optionally) some wiring of external configuration.

Clients of the final static constants don't need to worry about the external configuration.  The wiring framework (such as Spring) doesn't need to concern about the external configuration actually ends up in a bunch of static final constants.

In the trivial example I gave there is only one static final constant, K.  However, imagine we have multiple system constants.  A SystemParameterBean instance can be initialized once, and can then be used to initialize all the static final constants in SystemParameter, which are then accessed by clients in a simple way.  Like SystemParameter.K, SystemParameter.J, etc.

In such multiple-constant scenario, we can avoid init().getK() and init().getJ(), etc. but simply bean.getK() and bean.getJ().  The init() method implementation, which may incur additional overheads, should be done only once and not linear to the number of system constants.

For the lack of a better name, maybe we can call this "Static Final Constant Initialization" pattern ?

Hanson

On 9/23/05, David Holmes <[hidden email]> wrote:
I had presumed the code was an outline of something more elaborate and it was the "pattern" of initialization that was significant - otherwise it can be reduced to:
 
public static final long K = 20;
 
or if obtained from the "external" bean:
 
public static final long K = getExternalBean().getK();
 
there's no need to keep a reference to the bean. :)
 
David Holmes
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Hanson Char
Sent: Friday, 23 September 2005 5:24 PM
To: Joe Bowbeer
Cc: [hidden email]
Subject: Re: [concurrency-interest] Thread safe or not ?

I agree.  That's more streamlined.  Thanks!

Hanson

On 9/23/05, Joe Bowbeer <[hidden email]> wrote:
I guess I'm missing the point but GC hints always make me suspicious.

Can you assign K in the static initializer?  That would be more streamlined:

public class SystemParameter {
    public static final long K;
    static {
        SystemParameterBean bean = init();
        K = bean.getK();
    }
    // ...

On 9/22/05, Hanson Char <[hidden email]> wrote:

> I see, so the amended code below is both thread-safe and minimal, and
> hopefully with the correct comment.
>
>  Hanson
>
>  public class SystemParameter {
>      private static SystemParameterBean bean = init();
>      public static final long K = bean.getK();
>      static {
>          bean = null;    // hint to GC
>      }
>      private static SystemParameterBean init() {
>          // This part can be replaced by accessing an IoC framework
>          // such as Spring to retrieve an externally configured
>          // SystemParameterBean instance, as long as such
>          // instance is constructed and accessed by only 1 thread
>          // (ie not concurrently.)
>          SystemParameterBean bean = new SystemParameterBean();
>          bean.setK(20);
>          return bean;
>      }
>  }
>
>  public class SystemParameterBean {
>      private long k;
>
>      public long getK() {
>          return k;
>      }
>      public void setK(long k) {
>          this.k = k;
>      }
>  }
>
>
> On 9/23/05, David Holmes < [hidden email]> wrote:
> >
> > Hanson,
> >
> > SystemParameter.K is a static final long value that is initialized during
> static initialization from a newly constructed - and hence otherwise
> inaccessible - object. So as it stands it is always threadsafe to access it,
> as static initialization is itself threadsafe.
> >
> > I don't know why the bean variable is volatile if it is only accessed
> during static initialization. So it may not be minimal synchronization.
> >
> > However the comment:
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >
> > is not correct. If you use an externally configured bean object to
> initialize K then you need to be guaranteed that that beans k field has been
> correctly set and may not be concurrently set while being read from getK. As
> these are long values then atomicity of reads/writes does not apply and you
> may read a garbage value.
> >
> > Hope that helps.
> >
> > David Holmes
> >
> >
> >
> > -----Original Message-----
> > From: [hidden email]
> [mailto:[hidden email]]On
> Behalf Of Hanson Char
> > Sent: Friday, 23 September 2005 3:19 PM
> > To: [hidden email]
> > Subject: [concurrency-interest] Thread safe or not ?
> >
> > Assuming JDK5, is the following code always thread safe when
> SystemParameter.K is concurrently accessed  ?  If so, is the synchronization
> used in the code minimal ?  If not, why not ?
> >
> > Thanks in advance.
> >
> > Hanson
> >
> > public class SystemParameter {
> >     private static volatile SystemParameterBean bean = init();
> >     public static final long K = bean.getK();
> >     static {
> >         bean = null;    // hint to GC
> >     }
> >     private static SystemParameterBean init() {
> >         // This part can be replaced by accessing an IoC framework
> >         // such as Spring to retrieve an externally configured
> >         // SystemParameterBean instance.
> >         SystemParameterBean bean = new SystemParameterBean();
> >         bean.setK(20);
> >         return bean;
> >     }
> > }
> >
> > public class SystemParameterBean {
> >     private long k;
> >
> >     public long getK() {
> >         return k;
> >     }
> >     public void setK(long k) {
> >         this.k = k;
> >     }
> > }
> >
> >
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
<a href="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Thread safe or not ?

Olivier Dupuy
In reply to this post by Hanson Char
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > [mailto:[hidden email]]On
> > > Behalf Of Hanson Char
> > > > Sent: Friday, 23 September 2005 3:19 PM
> > > > To: [hidden email]
> > > > Subject: [concurrency-interest] Thread safe or not ?
> > > >
> > > > Assuming JDK5, is the following code always thread safe when
> > > SystemParameter.K is concurrently accessed ? If so, is the
> > synchronization
> > > used in the code minimal ? If not, why not ?
> > > >
> > > > Thanks in advance.
> > > >
> > > > Hanson
> > > >
> > > > public class SystemParameter {
> > > > private static volatile SystemParameterBean bean = init();
> > > > public static final long K = bean.getK();
> > > > static {
> > > > bean = null; // hint to GC
> > > > }
> > > > private static SystemParameterBean init() {
> > > > // This part can be replaced by accessing an IoC framework
> > > > // such as Spring to retrieve an externally configured
> > > > // SystemParameterBean instance.
> > > > SystemParameterBean bean = new SystemParameterBean();
> > > > bean.setK(20);
> > > > return bean;
> > > > }
> > > > }
> > > >
> > > > public class SystemParameterBean {
> > > > private long k;
> > > >
> > > > public long getK() {
> > > > return k;
> > > > }
> > > > public void setK(long k) {
> > > > this.k = k;
> > > > }
> > > > }
> > > >

    > these are long values then atomicity of reads/writes does not apply
and you
    > may read a garbage value.
    > >
    > > Hope that helps.
    > >
    > > David Holmes

Hi,

to add my 2 cents.
Outside of the initialization problem and as mentioned by David,
garbage can be retrieved and synchronization seems required on the getter and setter

from chapter 17.7 pp 579 of the Java language specification book
http://java.sun.com/docs/books/jls/download/langspec-3.0.pdf

17.7 Non-atomic Treatment of double and long
Some implementations may find it convenient to divide a single write action
on a 64-bit long or double value into two write actions on adjacent 32 bit values.
For efficiency's sake, this behavior is implementation specific; Java virtual
machines are free to perform writes to long and double values atomically or in two
parts.
For the purposes of the Java programming language memory model, a single
write to a non-volatile long or double value is treated as two separate writes: one
to each 32-bit half. This can result in a situation where a thread sees the first 32
bits of a 64 bit value from one write, and the second 32 bits from another write.
Writes and reads of volatile long and double values are always atomic. Writes to
and reads of references are always atomic, regardless of whether they are implemented
as 32 or 64 bit values.
VM implementors are encouraged to avoid splitting their 64-bit values where
possible. Programmers are encouraged to declare shared 64-bit values as volatile
or synchronize their programs correctly to avoid possible complications.

Thanks / Merci
Olivier DUPUY

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Joe Bowbeer
In reply to this post by David Holmes
On 9/23/05, David Holmes <[hidden email]> wrote:
>
> I had presumed the code was an outline of something more elaborate and it
> was the "pattern" of initialization that was significant - otherwise it can
> be reduced to:
>
> public static final long K = 20;
>

I was assuming there was some arbitrary amount of initialization
requiring a static block.

But if the bean instance is going to be nulled in the static block
anyway, then clearly all of the initialization can be moved into the
static block, thereby avoiding the confusing (and suspect)
instantiation in a static field and subsequent null assignment in the
static block.


On 9/23/05, David Holmes <[hidden email]> wrote:

>
> I had presumed the code was an outline of something more elaborate and it
> was the "pattern" of initialization that was significant - otherwise it can
> be reduced to:
>
> public static final long K = 20;
>
> or if obtained from the "external" bean:
>
> public static final long K = getExternalBean().getK();
>
> there's no need to keep a reference to the bean. :)
>
> David Holmes
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On
> Behalf Of Hanson Char
> Sent: Friday, 23 September 2005 5:24 PM
> To: Joe Bowbeer
> Cc: [hidden email]
> Subject: Re: [concurrency-interest] Thread safe or not ?
>
> I agree.  That's more streamlined.  Thanks!
>
> Hanson
>
>
> On 9/23/05, Joe Bowbeer <[hidden email]> wrote:
> > I guess I'm missing the point but GC hints always make me suspicious.
> >
> > Can you assign K in the static initializer?  That would be more
> streamlined:
> >
> > public class SystemParameter {
> >     public static final long K;
> >     static {
> >         SystemParameterBean bean = init();
> >         K = bean.getK();
> >     }
> >     // ...
> >
> > On 9/22/05, Hanson Char <[hidden email]> wrote:
> > > I see, so the amended code below is both thread-safe and minimal, and
> > > hopefully with the correct comment.
> > >
> > >  Hanson
> > >
> > >  public class SystemParameter {
> > >      private static SystemParameterBean bean = init();
> > >      public static final long K = bean.getK();
> > >      static {
> > >          bean = null;    // hint to GC
> > >      }
> > >      private static SystemParameterBean init() {
> > >          // This part can be replaced by accessing an IoC framework
> > >          // such as Spring to retrieve an externally configured
> > >          // SystemParameterBean instance, as long as such
> > >          // instance is constructed and accessed by only 1 thread
> > >          // (ie not concurrently.)
> > >          SystemParameterBean bean = new SystemParameterBean();
> > >          bean.setK(20);
> > >          return bean;
> > >      }
> > >  }
> > >
> > >  public class SystemParameterBean {
> > >      private long k;
> > >
> > >      public long getK() {
> > >          return k;
> > >      }
> > >      public void setK(long k) {
> > >          this.k = k;
> > >      }
> > >  }
> > >
> > >
> > > On 9/23/05, David Holmes < [hidden email]> wrote:
> > > >
> > > > Hanson,
> > > >
> > > > SystemParameter.K is a static final long value that is initialized
> during
> > > static initialization from a newly constructed - and hence otherwise
> > > inaccessible - object. So as it stands it is always threadsafe to access
> it,
> > > as static initialization is itself threadsafe.
> > > >
> > > > I don't know why the bean variable is volatile if it is only accessed
> > > during static initialization. So it may not be minimal synchronization.
> > > >
> > > > However the comment:
> > > >         // This part can be replaced by accessing an IoC framework
> > > >         // such as Spring to retrieve an externally configured
> > > >         // SystemParameterBean instance.
> > > >
> > > > is not correct. If you use an externally configured bean object to
> > > initialize K then you need to be guaranteed that that beans k field has
> been
> > > correctly set and may not be concurrently set while being read from
> getK. As
> > > these are long values then atomicity of reads/writes does not apply and
> you
> > > may read a garbage value.
> > > >
> > > > Hope that helps.
> > > >
> > > > David Holmes
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > [mailto:[hidden email]]On
> > > Behalf Of Hanson Char
> > > > Sent: Friday, 23 September 2005 3:19 PM
> > > > To: [hidden email]
> > > > Subject: [concurrency-interest] Thread safe or not ?
> > > >
> > > > Assuming JDK5, is the following code always thread safe when
> > > SystemParameter.K is concurrently accessed  ?  If so, is the
> synchronization
> > > used in the code minimal ?  If not, why not ?
> > > >
> > > > Thanks in advance.
> > > >
> > > > Hanson
> > > >
> > > > public class SystemParameter {
> > > >     private static volatile SystemParameterBean bean = init();
> > > >     public static final long K = bean.getK();
> > > >     static {
> > > >         bean = null;    // hint to GC
> > > >     }
> > > >     private static SystemParameterBean init() {
> > > >         // This part can be replaced by accessing an IoC framework
> > > >         // such as Spring to retrieve an externally configured
> > > >         // SystemParameterBean instance.
> > > >         SystemParameterBean bean = new SystemParameterBean();
> > > >         bean.setK(20);
> > > >         return bean;
> > > >     }
> > > > }
> > > >
> > > > public class SystemParameterBean {
> > > >     private long k;
> > > >
> > > >     public long getK() {
> > > >         return k;
> > > >     }
> > > >     public void setK(long k) {
> > > >         this.k = k;
> > > >     }
> > > > }
> > > >

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Dawid Kurzyniec
In reply to this post by Hanson Char
Hanson Char wrote:

> That's exactly right - very astute observation as usual.  It's an
> outline of a pattern for initializing, in a thread-safe manner,
> multiple final static constants via (optionally) some wiring of
> external configuration.
>
> Clients of the final static constants don't need to worry about the
> external configuration.  The wiring framework (such as Spring) doesn't
> need to concern about the external configuration actually ends up in a
> bunch of static final constants.
>
> In the trivial example I gave there is only one static final constant,
> K.  However, imagine we have multiple system constants.  A
> SystemParameterBean instance can be initialized once, and can then be
> used to initialize all the static final constants in SystemParameter,
> which are then accessed by clients in a simple way.  Like
> SystemParameter.K, SystemParameter.J, etc.
>
> In such multiple-constant scenario, we can avoid init().getK() and
> init().getJ(), etc. but simply bean.getK() and bean.getJ().  The
> init() method implementation, which may incur additional overheads,
> should be done only once and not linear to the number of system constants.
>
I apologize for such a delay in responding, but, if you move init() to
the static initializer, you can make the bean a local variable,
obviating the need to store it in a static field even though you access
it more than once:

public class SystemParameter {
    public static final long K;
    public static final long L;
    ...
    static {
        SystemParameterBean bean = init();
        K = bean.getK();
        L = bean.getL();
        ...
    }


Regards,
Dawid

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Thread safe or not ?

Hanson Char
Yes, thanks.  Indeed the better solution you point out has also been pointed out by Joe Bowbeer in an earlier response to this thread.

Hanson

On 10/5/05, Dawid Kurzyniec <[hidden email]> wrote:
Hanson Char wrote:

> That's exactly right - very astute observation as usual.  It's an
> outline of a pattern for initializing, in a thread-safe manner,
> multiple final static constants via (optionally) some wiring of
> external configuration.
>
> Clients of the final static constants don't need to worry about the
> external configuration.  The wiring framework (such as Spring) doesn't
> need to concern about the external configuration actually ends up in a
> bunch of static final constants.
>
> In the trivial example I gave there is only one static final constant,
> K.  However, imagine we have multiple system constants.  A
> SystemParameterBean instance can be initialized once, and can then be
> used to initialize all the static final constants in SystemParameter,
> which are then accessed by clients in a simple way.  Like
> SystemParameter.K, SystemParameter.J, etc.
>
> In such multiple-constant scenario, we can avoid init().getK() and
> init().getJ(), etc. but simply bean.getK() and bean.getJ().  The
> init() method implementation, which may incur additional overheads,
> should be done only once and not linear to the number of system constants.
>
I apologize for such a delay in responding, but, if you move init() to
the static initializer, you can make the bean a local variable,
obviating the need to store it in a static field even though you access
it more than once:

public class SystemParameter {
    public static final long K;
    public static final long L;
    ...
    static {
        SystemParameterBean bean = init();
        K = bean.getK ();
        L = bean.getL();
        ...
    }


Regards,
Dawid



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest