Primitives wrappers and visibility problems

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

Primitives wrappers and visibility problems

alarmnummer
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?
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Primitives wrappers and visibility problems

Kasper Nielsen-2
Peter Veentjer 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?
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>

You could take a peek in the source:

     /**
      * The value of the <code>Integer</code>.
      *
      * @serial
      */
     private final int value;

     /**
      * Constructs a newly allocated <code>Integer</code> object that
      * represents the specified <code>int</code> value.
      *
      * @param   value   the value to be represented by the
      * <code>Integer</code> object.
      */
     public Integer(int value) {
        this.value = value;
     }

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

Re: Primitives wrappers and visibility problems

Ernst, Matthias
In reply to this post by alarmnummer
> 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@Java 1.5.0_07:
    /**
     * The value of the <code>Integer</code>.
     *
     * @serial
     */
    private final int value;


Matthias

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

Re: Primitives wrappers and visibility problems

alarmnummer
In reply to this post by Kasper Nielsen-2
I have checked the source of java 1.3.1.18 and it doesn't contain a
final. The final must have been introduced in 1.4 or 1.5.

And the final doesn't add any value in vm that 'support' the older JMM anyway ;)

But it is good to know it is final in the newest version of Java.

On 8/23/06, Kasper Nielsen <[hidden email]> wrote:

> Peter Veentjer 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?
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
> You could take a peek in the source:
>
>     /**
>      * The value of the <code>Integer</code>.
>      *
>      * @serial
>      */
>     private final int value;
>
>     /**
>      * Constructs a newly allocated <code>Integer</code> object that
>      * represents the specified <code>int</code> value.
>      *
>      * @param   value   the value to be represented by the
>      *                 <code>Integer</code> object.
>      */
>     public Integer(int value) {
>        this.value = value;
>     }
>
> - Kasper
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Primitives wrappers and visibility problems

Joe Bowbeer
In reply to this post by alarmnummer
On 8/23/06, Peter Veentjer <[hidden email]> 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?

In Java 5, Integer *does* use a final.  See below.

If it didn't use final, then it would still be thread safe -- because
it is immutable.  But it would not be immune to unsafe publication.

    private final int value;

    public Integer(int value) {
        this.value = value;
    }

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

Re: Primitives wrappers and visibility problems

alarmnummer
If the field isn't final, it could be subject to out of order reads
and writes, meaning that a different thread could see a partially
created object -> not threadsafe.

If I'm missing something, please enlighten me :) The subject is very
interesting and the best way to get a better understanding is to ask
questions.

On 8/23/06, Joe Bowbeer <[hidden email]> wrote:

> On 8/23/06, Peter Veentjer <[hidden email]> 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?
>
> In Java 5, Integer *does* use a final.  See below.
>
> If it didn't use final, then it would still be thread safe -- because
> it is immutable.  But it would not be immune to unsafe publication.
>
>    private final int value;
>
>    public Integer(int value) {
>        this.value = value;
>    }
>
> --Joe
> _______________________________________________
> 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: Primitives wrappers and visibility problems

alarmnummer
In reply to this post by Ernst, Matthias
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 <[hidden email]> 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@Java 1.5.0_07:
>    /**
>     * The value of the <code>Integer</code>.
>     *
>     * @serial
>     */
>    private final int value;
>
>
> Matthias
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Primitives wrappers and visibilityproblems

Stefan Skoglund
Re: [concurrency-interest] Primitives wrappers and visibilityproblems
 
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: [hidden email] genom Peter Veentjer
Skickat: on 2006-08-23 13:05
Till: Ernst, Matthias
Kopia: [hidden email]
Ä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 <[hidden email]> 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@Java 1.5.0_07:
>    /**
>     * The value of the <code>Integer</code>.
>     *
>     * @serial
>     */
>    private final int value;
>
>
> Matthias
>
_______________________________________________
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: Primitives wrappers and visibilityproblems

alarmnummer
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 <[hidden email]> 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: [hidden email] genom
> Peter Veentjer
> Skickat: on 2006-08-23 13:05
> Till: Ernst, Matthias
> Kopia: [hidden email]
> Ä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 <[hidden email]> 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@Java 1.5.0_07:
> >    /**
> >     * The value of the <code>Integer</code>.
> >     *
> >     * @serial
> >     */
> >    private final int value;
> >
> >
> > Matthias
> >
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> 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 <[hidden email]> 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@Java 1.5.0_07:
> >    /**
> >     * The value of the <code>Integer</code>.
> >     *
> >     * @serial
> >     */
> >    private final int value;
> >
> >
> > Matthias
> >
> _______________________________________________
> 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: Primitives wrappers and visibility problems

Joe Bowbeer
In reply to this post by alarmnummer
The distinction between thread safety and safe publication was
discussed earlier on this list (Aug 2) as "concurrency errors in
java.lang.Throwable".

David Holmes wrote:

"Being safely publishable even when published without synchronization
goes a step beyond basic thread-safety."

Immutable classes like Integer are in fact easy to innoculate against
unsafe publication, but they are "thread-safe" (according to our
definition) even without the extra security boost.

Does the earlier discussion help clarify this?


On 8/23/06, Peter Veentjer <[hidden email]> wrote:

> 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 <[hidden email]> 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@Java 1.5.0_07:
> >    /**
> >     * The value of the <code>Integer</code>.
> >     *
> >     * @serial
> >     */
> >    private final int value;
> >
> >
> > Matthias
> >
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Primitives wrappers and visibilityproblems

Chris Purcell
In reply to this post by alarmnummer
> 1) mem = allocmem(MyInt)
> 2) mem.value = 10
> 3) globalfield = mem

If 2 is properly ensconced in a constructor, and 3 is executed  
outside of the constructor, the language guarantees that 2 happens-
before 3, even if globalfield is not volatile.

Chris

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

Re: Primitives wrappers and visibilityproblems

Stefan Skoglund
In reply to this post by alarmnummer
Re: [concurrency-interest] Primitives wrappers and visibilityproblems
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:[hidden email]]
Skickat: on 2006-08-23 13:29
Till: Stefan Skoglund
Kopia: Ernst, Matthias; [hidden email]
Ä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 <[hidden email]> 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: [hidden email] genom
> Peter Veentjer
> Skickat: on 2006-08-23 13:05
> Till: Ernst, Matthias
> Kopia: [hidden email]
> Ä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 <[hidden email]> 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@Java 1.5.0_07:
> >    /**
> >     * The value of the <code>Integer</code>.
> >     *
> >     * @serial
> >     */
> >    private final int value;
> >
> >
> > Matthias
> >
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> 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 <[hidden email]> 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@Java 1.5.0_07:
> >    /**
> >     * The value of the <code>Integer</code>.
> >     *
> >     * @serial
> >     */
> >    private final int value;
> >
> >
> > Matthias
> >
> _______________________________________________
> 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: Primitives wrappers and visibility problems

Brian Goetz
In reply to this post by alarmnummer
> If the field isn't final, it could be subject to out of order reads
> and writes, meaning that a different thread could see a partially
> created object -> not threadsafe.

Only if the object is improperly published -- published using a data
race.  If it is properly published (statically initialized, published
via a volatile, published/consumed with synchronization), it is
guaranteed to work because it is effectively immutable.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest