Michael Farragher

Ranch Hand
+ Follow
since May 01, 2019
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
16
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Michael Farragher

In Java Concurrency in Practice, it says :

Immutable objects can be published through any mechanism
Effectively immutable objects must be safely published
.....

So if I've got :





Could someone give an illustration of the points above ? I'd be interested to see the difference
One thing that puzzles me in JCIP is when it talks about immutable objects. It says that immutable objects are immune to improper publication.

It gives this example :




In another class, you've got



It says this is publishing an object without adequate synchronization. But it says that making n in Holder final would make the class immutable and would then be immune to improper publication. But you'd still need to make the holder ref volatile - or employ anothre synchonization mechanism - so that reading threads would see the right object ?!!? In other words you'd need to publish it properly. Can someone resolve my confusion ?! Thanks
I guess class B could be rewritten as



??
"Safe publication is sufficient for other threads to safely access objects that are not going to be modified after publication without additional synchronization.
The safe publication mechanisms all guarantee that the as-published state of an object is visible to all accessing threads as soon as the reference to it is visible,
and if that state is not going to be changed again, this is sufficient to ensure that any access is safe"

So if I've got



Is class B thread-safe ?
I'm never setting the reference to null.

It's just that without synchronization Thread B could read obj as null and then read it as non-null (or keep reading it as null).

I was just wondering if it could read it as non -null to start off with, then null subsequently.

(I know this is an academic question - just synchronize, I hear you say !!!)
Say Thread A executes



Then Thread B accesses this object without synchronization and sees a non-null value in obj. Will subsequent reads of obj by B always be non-null ?
I think what confused me was the expression "happens-before". They should have come up with something that implies visibility - perhaps "consequential"
But if you were to ditch the boolean value and make the int volatile and the threads hit the methods simultaneously, are you saying the read wouldn't take place first ? Why couldn't we read the default value ?

STOP PRESS :

I'm beginning to see. The reason why HP(13, 21) is because writes before a volatile is written to in one thread are visible after the volatile is read in another thread ( as well the volatile being used in the while loops).
I'd never heard of that phrase until recently ( at least, not in the context of threading)

In Java Concurrency in Practice, it says "To guarantee that the thread executing action B can see the results of action A (whether or not A and B occur in different threads), there must be a happens-before relationship between A and B".

But if I've got this class :




and thread 1 executes setInteger(5) on an instance of this class and thread 2 then executes getInteger on the same instance, thread 2 isn't guaranteed to read the latest value, so what's the significance of happens-before ?

Thanks
I guess ps could be null to the reading thread too
Just to be clear, I'm not talking about the mySet reference or the final modifier, I'm talking about the map member that's set up in the HashSet constructor
Which really takes me back to my first question.

If Thread A executes the mySet assignment ( which creates a HashMap) and other threads execute the synchronized methods, how do we know that the map won't be null and point to the correct object ?
One final question ( and sorry to be pendantic) :

If I removed synchronized from the getMap method, would thread B still be pointing at the object initialised by thread A (of course, not a thread safe object)

So if I didn't return the map but just used it, I'd be ok ?
So Stephan, if I go

final Object o = new MyObject();

not only will o always point at an instance of MyObject, but all the fields of this type (and their fields) will be initialised, and other threads will see this initialised state provided that it's accessed appropriately ?!?

So if this is class MyObject :

class MyObject{
   
  private Map<String, String> map = new HashMap<>();

  public synchronized Map<String, String> getMap(){
     return map;
  }
}


and thread A creates an instance of this :

final Object o = new MyObject();

and then thread B calls getMap() on this instance, I'd be ok ??!

Without the final modifier, I guess I'd have to synchronize on the assignment.