[concurrency-interest] Primitives wrappers and visibilityproblems

Stefan Skoglund Stefan.Skoglund at it-huset.se
Wed Aug 23 08:10:55 EDT 2006


Yes! Euh, what is the first way the int could leak?
 
The final field is gurateed to be written after the ctor. A non final field could be written just about whenever, unless other synchronization means are used. I.e. the reordering will not reach past the ctor for a final field. Right? A write of a non final int could potentially be stopped from having go any further than to a CPU register, according to spec. Right?
 
/Stefan

________________________________

Från: Peter Veentjer [mailto:alarmnummer at gmail.com]
Skickat: on 2006-08-23 13:29
Till: Stefan Skoglund
Kopia: Ernst, Matthias; concurrency-interest at cs.oswego.edu
Ämne: Re: [concurrency-interest] Primitives wrappers and visibilityproblems



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
>
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060823/3d454365/attachment.html 


More information about the Concurrency-interest mailing list