[concurrency-interest] Primitives wrappers and visibilityproblems

Peter Veentjer alarmnummer at gmail.com
Wed Aug 23 07:29:38 EDT 2006


There also is another way the value of the 'myint' could leak. The vm
is allowed to reorden instructions as long as the reordening is not
visible in the executing thread.

eg:

1) mem = allocmem(MyInt)
2) mem.value = 10
3) globalfield = mem

This could be reordened to:

1) mem = allocmem(MyInt)
2) globalfield = mem
3) mem.value = 10

In this case the MyInt is visible in other threads (they can see the
globalfield) before the mem.value=10 is called. The consequence is
that other threads can see a partially created MyInt.

And this is not threadsafe imho.

On 8/23/06, Stefan Skoglund <Stefan.Skoglund at it-huset.se> wrote:
>
>
>
> No, its not thread safe, and you got the idea. The final fields is not
> guaranteed to be written until after the ctor.
> So, don't let this leak within your ctor, your final field could be used
> from another thread, before its actually written.
>
> Correct me if I'm wrong
> Cheers Stefan
>
> ________________________________
> Från: concurrency-interest-bounces at cs.oswego.edu genom
> Peter Veentjer
> Skickat: on 2006-08-23 13:05
> Till: Ernst, Matthias
> Kopia: concurrency-interest at cs.oswego.edu
> Ämne: Re: [concurrency-interest] Primitives wrappers and visibilityproblems
>
>
>
> But what if it wasn't final. Example:
>
> public class MyInt{
>     private int value;
>
>     public MyInt(int value){
>         this.value = value;
>     }
>
>     public int getValue(){
>         return value;
>     }
> }
>
> Is the following class threadsafe?
>
> 1) because it is subject to out of order writes, other threads could
> see a partially created MyInt (with the default value 0). A moment
> later (when the constructor is called) they could see it with the
> correct value.
>
> 2) because value is not safely published, it could happen that other
> threads never see the new value.
>
> So I would call this class not threadsafe.
>
> Maybe something is wrong with my definition of threadsafe. Maybe I'm
> missing something.
>
> On 8/23/06, Ernst, Matthias <matthias.ernst at coremedia.com> wrote:
> > > I have another question about visibility problems. Someone suggested
> > > to me that the primitve wrappers (like Integer) don't use a final
> > > field for the primitive they contain. This would make them not
> > > threadsafe. Is this correct?
> >
> > I was about to write a lengthy response. It turns out that someone's
> > suggestion is just wrong:
> >
> > java.lang.Integer at Java 1.5.0_07:
> >    /**
> >     * The value of the <code>Integer</code>.
> >     *
> >     * @serial
> >     */
> >    private final int value;
> >
> >
> > Matthias
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> But what if it wasn't final. Example:
>
> public class MyInt{
>     private int value;
>
>     public MyInt(int value){
>         this.value = value;
>     }
>
>     public int getValue(){
>         return value;
>     }
> }
>
> Is the following class threadsafe?
>
> 1) because it is subject to out of order writes, other threads could
> see a partially created MyInt (with the default value 0). A moment
> later (when the constructor is called) they could see it with the
> correct value.
>
> 2) because value is not safely published, it could happen that other
> threads never see the new value.
>
> So I would call this class not threadsafe.
>
> Maybe something is wrong with my definition of threadsafe. Maybe I'm
> missing something.
>
> On 8/23/06, Ernst, Matthias <matthias.ernst at coremedia.com> wrote:
> > > I have another question about visibility problems. Someone suggested
> > > to me that the primitve wrappers (like Integer) don't use a final
> > > field for the primitive they contain. This would make them not
> > > threadsafe. Is this correct?
> >
> > I was about to write a lengthy response. It turns out that someone's
> > suggestion is just wrong:
> >
> > java.lang.Integer at Java 1.5.0_07:
> >    /**
> >     * The value of the <code>Integer</code>.
> >     *
> >     * @serial
> >     */
> >    private final int value;
> >
> >
> > Matthias
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>



More information about the Concurrency-interest mailing list