Comments on From Java to Java EE: The power of the final keyword - updated

There is a difference between creating new thread ...

2009-04-19T22:39:00.000+02:00

There is a difference between creating new thread and letting thread pool to handle the runnable. In first case, you are invoking explicit memory synchronization barrier, in second it is not really guaranteed (might be implementation dependent I think).

In Sun JDK implementation, I think it will work even with executor pool. Worker class is doing the runLock.lock(); before execution of actual Runnable starts (so it is loading state from common memory). Caller thread on the other hand is synchronizing in submit, which is calling execute, which is calling addIfUnderCorePoolSize, which will flush there with unlock before using the thread to run the runnable OR offering it to blocking queue from which Worker thread will retrieve it, also creating synchronization point.

I'm not sure if this is possible to create Executor service which would allow for different behaviour and still be compatible with all the specs - but it is also not clearly specified that memory is synchronized before passing data to worker threads. In such case, it is always better to stay on the safe side. In fact, it is always better to stay on the safe side, even in example you gave here, because it reduces amount of magic dependencies in code and allows nasty surprises when code is later refactored by somebody else. Plus final fields make things easier to understand even in single threaded code ;)

Easiest example of need for final is non-synchronized static variable which is pointing to some singleton-like data. If you don't care about possible multiple initializations, you can do lazy initialization of it from calling thread if needed. In such case, some other thread running 'later' might see null and will initialize it again - but it is not an issue. What it the issue is that if you use non-final fields in it, it can see a reference to the 'singleton', but still half-initialized/null contents, even if you initialized it fully before assigning to static variable.

"@Shantany & Ram - you're partially r...

2009-04-19T21:31:00.000+02:00

"@Shantany & Ram - you're partially right :) I forgot to add very important detail that it's safe only fore reads i.e. when we assume map.put(...) statement will never occur."

If you never intended to make your map modifiable, the example makes absolutely no sense. I agree with abby that there was not a problem to begin with that you are trying to solve with your immutable class.

abies is entirely correct. The JLS specifies that ...

2009-04-18T23:15:00.000+02:00

abies is entirely correct. The JLS specifies that on Thread.start() happens before any other action on that thread. Thus, with or without final in, the new Thread will see the correct data for SomeClass. Since SomeClass and the Thread are constructed on the Main thread before the call to start() happens, then I would be interested to know how you think a NullPointerException can happen on the newly spawned Thread.

You sound resonable and this is the reason why I h...

2009-04-18T19:36:00.000+02:00

You sound resonable and this is the reason why I have to confront your opinion with this comment: http://java2jee.blogspot.com/2008/11/java-concurrency-is-easy-combining.html?showComment=1226948760000#c4144762493589566546

Any ideas? Does it make a difference when you create new thread and when you submit your task to the executore service?

Sorry to be nitpicking, but multithreading program...

2009-04-18T13:25:00.000+02:00

Sorry to be nitpicking, but multithreading programming is about details:

"Look - in the code I provided I create new thread together with creating the object of SimpleClass."

No, you are creating new thread after SimpleClass has finished initialization. Even that doesn't matter so much, as it is the 'start' method which is really spawning a new execution thread, which is called even after Thread constructor.

From
http://gee.cs.oswego.edu/dl/cpj/jmm.html

"Thread.start has the same memory effects as a lock release by the thread calling start, followed by a lock acquire by the started thread."

On lock release, thread view of data is flushed to common memory. On lock acquire, thread view of data is synced from common memory. This means, that anything put in code of calling thread before .start is called will be fully visible to new thread. As SimpleClass is fully finishes initialization even without final keyword, it will be visible to spawned thread.

Only tricky part with thread creation is if you spawn a new thread from constructor of the object and let 'this' pointer escape to the new thread. In such case, you are out of luck even if final keyword is used.

I think that
http://moonbase.rydia.net/mental/blog/programming/java/the-java-memory-model-for-programmers
got it right in the small table in the middle of the post. You can see there
Writes up to and including…
a call to Thread.start
...are made visible to…
the newly started thread.

You may want to browse the rest of the cases to get better understanding of the relations between threads.

ERRATA: when we assume map.put(...) statement will...

2009-04-18T12:19:00.000+02:00

ERRATA: when we assume map.put(...) statement will never occur AFTER the object is created. On the other hand preProcessMap() can do whathever reads and writes it likes because until the constructor is finished final fields are safe to modify.

@Shantany & Ram - you're partially right :...

2009-04-18T11:30:00.000+02:00

@Shantany & Ram - you're partially right :) I forgot to add very important detail that it's safe only fore reads i.e. when we assume map.put(...) statement will never occur.

@abies - synchronization of start() method only guarantees that "It is never legal to start a thread more than once." not that the initialization of the object in another thread will finishe before starting this thread. Look - in the code I provided I create new thread together with creating the object of SimpleClass. You cannot be sure what will be done first because the second thread is being created.

Thread.start is synchronized. Before that new thre...

2009-04-18T08:38:00.000+02:00

Thread.start is synchronized. Before that new thread is not existing, so it cannot have a copy of old memory from before that moment.

I think that your particular example will work perfectly well without final keyword.

Which clearly shows that concurrency is NOT easy ;)

Agree with Shantanu, it is too simplistic to assum...

2009-04-18T07:47:00.000+02:00

Agree with Shantanu, it is too simplistic to assume final is be all and end all for being thread safe.

It will be safer to say synchronized is what makes things thread safe.

Of course that comes with a cost. We can reduce the cost by reducing the scope of synchronization through some strategies.

Using the appropriate concurrent utils in jdk5+ is one way to achieve this.

Using thread local variables is another.

Limiting all modifications of shared object to a dedicated thread is yet another.

Ensuring every thread has its own copy of data to work on is yet another - maybe this is truly what you wanted to get at here.

Remember that a completely immutable object is not very useful for most processing purposes.

This one is a really bad example. What if you acci...

2009-04-18T05:50:00.000+02:00

This one is a really bad example. What if you accidentally write a map.put(...) statement in the code somewhere? Or what if a maintenance programmer does that?

final is fine for primitives. But for objects you need immutable data types (e.g. Collections.unmodifiableMap(...)).