a question about concurrent safe access

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

a question about concurrent safe access

Yechiel Feffer
a question about concurrent safe access

Hi all
say I have a pointer ( reference) to an object ( A). This reference is changed to point at object B. I have threads that concurrently are using that reference to get the object it points at. I dont want to synchronize the usage of the reference. Is it safe to do so, i.e. if I dont use a lock and I dont declare the reference volatile will I always get object A or B or do I have a risk of getting "dirty" inconsistent pointer , i.e. is assigning a pointer always atomic  ?

Regrds,
Yechiel  


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

Re: a question about concurrent safe access

Doug Lea
Yechiel Feffer wrote:
> Hi all
> say I have a pointer ( reference) to an object ( A). This reference is
> changed to point at object B. I have threads that concurrently are using
> that reference to get the object it points at. I dont want to
> synchronize the usage of the reference. Is it safe to do so, i.e. if I
> dont use a lock and I dont declare the reference volatile will I always
> get object A or B or do I have a risk of getting "dirty" inconsistent
> pointer , i.e. is assigning a pointer always atomic  ?
>

Pleae declare the field volaitle.

One of the goals of the JSR133 JMM revision was to make answers to
questions like this nearly automatic: If you have a field that is not
consistently protected by some kind of synchronization, then it should
either be declared volatile or final. (Final doesn't apply here.)

If you don't declare it volatile, then you have to be prepared for
suprising things to happen, like begin able to read the reference
but not seeing the current values of the fields of the referred-to
object. The gruesome details are in chapter 17 of the revised JLS
(http://java.sun.com/docs/books/jls/index.html).

-Doug


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

Re: a question about concurrent safe access

Stefan Skoglund
In reply to this post by Yechiel Feffer
Theoretically, I guess you could get a dirty reference if you used a
volatile reference. Consider the two treads X and Y. And consider
volatile reference R pointing to A, seen by both threads. If X creates
object B and lets R point to B, then Y would see reference R point to
where B should reside. But since no memory synchronization is guarantied
to have occurred. except the volatile reference. it would be possible
that Y sees a dirty reference.

However as I understand, the current implementation of volatile reads
and writes, does perform full blown memory synchronization between two
threads, exchanging information through a volatile reference. So the
dirty reference would never appear. I'm not sure one should rely the
fullblown memory synchronization though.

I guess one of the experts could verify this.

yours
/Stefan


Yechiel Feffer wrote:

> Hi all
> say I have a pointer ( reference) to an object ( A). This reference is
> changed to point at object B. I have threads that concurrently are
> using that reference to get the object it points at. I dont want to
> synchronize the usage of the reference. Is it safe to do so, i.e. if I
> dont use a lock and I dont declare the reference volatile will I
> always get object A or B or do I have a risk of getting "dirty"
> inconsistent pointer , i.e. is assigning a pointer always atomic  ?
>
> Regrds,
> Yechiel  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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: a question about concurrent safe access

Brian Goetz
In reply to this post by Yechiel Feffer
> say I have a pointer ( reference) to an object ( A). This reference is
> changed to point at object B. I have threads that concurrently are using
> that reference to get the object it points at. I dont want to
> synchronize the usage of the reference. Is it safe to do so, i.e. if I
> dont use a lock and I dont declare the reference volatile will I always
> get object A or B or do I have a risk of getting "dirty" inconsistent
> pointer , i.e. is assigning a pointer always atomic  ?

The assignment of the _value_ of the pointer is atomic.  However, that
does not mean this idiom is safe, because this does not promise anything
about the object _pointed to_.  It is possible to see inconsistent
values for the fields of the pointed-to object unless it is immutable.

Just writing a shared pointer is a form of "unsafe publication".

Example:

class Sum {
   // Invariant: a+b = sum
   public int a, b, sum;

   Sum(int a, int b) {
     this.a = a;
     this.b = b;
     this.sum = a+b;
   }
}

public static Sum sum;

Thread A:  sum= new Sum (3,4);

Thread B:  Sum mySum = sum;

At the end of this, Thread B could see sum have any of the following
values for (a,b,sum):

   (0,0,0) *
   (0,0,7)
   (0,4,0)
   (3,0,0)
   (3,4,0)
   (3,0,7)
   (0,4,7)
   (3,4,7) *

The ones labeled with * are the only ones which are "consistent".

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

RE: a question about concurrent safe access

David Holmes
In reply to this post by Stefan Skoglund
Stefan,

As of Java 5 the new Java Memory Model gives very precise semantics to
volatile and you are indeed guaranteed certain behaviour - it is not an
artefact of an implementation.

The JMM guarantees that a write of a volatile variable happens-before a read
of that variable that sees the written value. This means that if Thread-X
does:

  Global.R = new B();

and Thread-Y reads Gobal.R and finds the reference to the B object, then it
is guaranteed to see everything that occurred in Thread-X prior to the
assignment to Global.R ie all the construction actions.

David Holmes


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> Stefan Skoglund
> Sent: Monday, 19 September 2005 9:37 PM
> To: Yechiel Feffer
> Cc: [hidden email]
> Subject: Re: [concurrency-interest] a question about concurrent
> safe access
>
>
> Theoretically, I guess you could get a dirty reference if you used a
> volatile reference. Consider the two treads X and Y. And consider
> volatile reference R pointing to A, seen by both threads. If X creates
> object B and lets R point to B, then Y would see reference R point to
> where B should reside. But since no memory synchronization is guarantied
> to have occurred. except the volatile reference. it would be possible
> that Y sees a dirty reference.
>
> However as I understand, the current implementation of volatile reads
> and writes, does perform full blown memory synchronization between two
> threads, exchanging information through a volatile reference. So the
> dirty reference would never appear. I'm not sure one should rely the
> fullblown memory synchronization though.
>
> I guess one of the experts could verify this.
>
> yours
> /Stefan
>
>
> Yechiel Feffer wrote:
>
> > Hi all
> > say I have a pointer ( reference) to an object ( A). This reference is
> > changed to point at object B. I have threads that concurrently are
> > using that reference to get the object it points at. I dont want to
> > synchronize the usage of the reference. Is it safe to do so, i.e. if I
> > dont use a lock and I dont declare the reference volatile will I
> > always get object A or B or do I have a risk of getting "dirty"
> > inconsistent pointer , i.e. is assigning a pointer always atomic  ?
> >
> > Regrds,
> > Yechiel
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >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
>

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

RE: a question about concurrent safe access

Peter Veentjer - Anchor Men
In reply to this post by Yechiel Feffer
 
But what can happen if a field is used in a multithreaded environment
and it isn`t synchronized or volatile. Could you get some serious
vm-errors (or totally unacceptable behaviour of the program)? Or just an
old reference?

-----Oorspronkelijk bericht-----
Van: [hidden email]
[mailto:[hidden email]] Namens David Holmes
Verzonden: dinsdag 20 september 2005 1:31
Aan: Stefan Skoglund
CC: [hidden email]
Onderwerp: RE: [concurrency-interest] a question about concurrent safe
access

Stefan,

As of Java 5 the new Java Memory Model gives very precise semantics to
volatile and you are indeed guaranteed certain behaviour - it is not an
artefact of an implementation.

The JMM guarantees that a write of a volatile variable happens-before a
read of that variable that sees the written value. This means that if
Thread-X
does:

  Global.R = new B();

and Thread-Y reads Gobal.R and finds the reference to the B object, then
it is guaranteed to see everything that occurred in Thread-X prior to
the assignment to Global.R ie all the construction actions.

David Holmes


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Stefan

> Skoglund
> Sent: Monday, 19 September 2005 9:37 PM
> To: Yechiel Feffer
> Cc: [hidden email]
> Subject: Re: [concurrency-interest] a question about concurrent safe
> access
>
>
> Theoretically, I guess you could get a dirty reference if you used a
> volatile reference. Consider the two treads X and Y. And consider
> volatile reference R pointing to A, seen by both threads. If X creates

> object B and lets R point to B, then Y would see reference R point to
> where B should reside. But since no memory synchronization is
> guarantied to have occurred. except the volatile reference. it would
> be possible that Y sees a dirty reference.
>
> However as I understand, the current implementation of volatile reads
> and writes, does perform full blown memory synchronization between two

> threads, exchanging information through a volatile reference. So the
> dirty reference would never appear. I'm not sure one should rely the
> fullblown memory synchronization though.
>
> I guess one of the experts could verify this.
>
> yours
> /Stefan
>
>
> Yechiel Feffer wrote:
>
> > Hi all
> > say I have a pointer ( reference) to an object ( A). This reference
> > is changed to point at object B. I have threads that concurrently
> > are using that reference to get the object it points at. I dont want

> > to synchronize the usage of the reference. Is it safe to do so, i.e.

> > if I dont use a lock and I dont declare the reference volatile will
> > I always get object A or B or do I have a risk of getting "dirty"
> > inconsistent pointer , i.e. is assigning a pointer always atomic  ?
> >
> > Regrds,
> > Yechiel
> >
> >---------------------------------------------------------------------
> >---
> >
> >_______________________________________________
> >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
>

_______________________________________________
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: a question about concurrent safe access

Joe Bowbeer
On 9/20/05, Peter Veentjer - Anchor Men <[hidden email]> wrote:
>
> But what can happen if a field is used in a multithreaded environment
> and it isn`t synchronized or volatile. Could you get some serious
> vm-errors (or totally unacceptable behaviour of the program)? Or just an
> old reference?
>

The answer is C: Just an old reference

Your thread must see a live reference (or null) written by some thread
-- but it might not see the most recent value written.

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

Re: a question about concurrent safe access

Brian Goetz
>>But what can happen if a field is used in a multithreaded environment
>>and it isn`t synchronized or volatile. Could you get some serious
>>vm-errors (or totally unacceptable behaviour of the program)? Or just an
>>old reference?
>
> The answer is C: Just an old reference

More precisely:

You can get an old or new reference to the object being referenced.  But
in the event you see the new reference, the state _of that referenced
object_ may still be garbage unless that object it itself immutable or
thread-safe.

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

Re: a question about concurrent safe access

Larry Riedel

> > But what can happen if a field is used in a multithreaded
> > environment and it isn`t synchronized or volatile. Could
> > you get some serious vm-errors (or totally unacceptable
> > behaviour of the program)? Or just an old reference?
>
> [...]
>
> You can get an old or new reference to the object being
> referenced.  But in the event you see the new reference, the
> state _of that referenced object_ may still be garbage unless
> that object it itself immutable or thread-safe.

A different kind of garbage from when an object which is not
thread-safe may in general violate its "invariants" when used
concurrently by multiple threads?


Larry

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

RE: a question about concurrent safe access

David Holmes
> A different kind of garbage from when an object which is not
> thread-safe may in general violate its "invariants" when used
> concurrently by multiple threads?

The same kind of "garbage". You will never see a value that was never
written to a field (with the exception of long and doubles).

David Holmes

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