Monday, April 27, 2009

Certified Scrum Master Training in Gdańsk

I hope you already know that a cool company that is definitely one generation ahead than their competitors (at least as far as the way they work is concerned) called Spartez organizes the first CSM Training in northern Poland, namely in Gdańsk. The training will be led by famous Henrik Kniberg from whose book my adventure with real Scrum began. It is really a PITTY I will not be there :(

But anyway - if you live somewhere in the central, eastern or northern Europe this training is definitely worth taking. I took CSM course in Zurich last week led by Angela Druckman and am very satisfied. This training is really worth it's price (or even more because I think the training is quite cheap).

Don't waste your time and sign up for this CSM session.

Friday, April 17, 2009

The power of the final keyword - updated

Picture courtesy of Okko Pyykkö@flickr
These two articles of Alex Miller:clearly explain why using final fields in concurrent programs is extremely powerful and safe (thread-safe).

Take a look a this simple example:

public class SomeClass implements Runnable {
private final LinkedHashMap map;

public SomeClass(LinkedHashMap copiedMap) {
map = copiedMap;
preProcessMap();
}

private void preProcessMap() {
//some non-trivial and not-so-short computations
}

// A read method
public Object get(Object key) {
return map.get(key);
}

public void run() {
//assume that in this method only
//unsynchronized read operations on map may occur
//any unsynchronized write operation is not thread-safe
}
// etc...
}

public class Main {
public static void main(String[] args) {
LinkedHashMap map = // map creation
// map initialization
new Thread(new SomeClass(map)).start();
// etc.
}
}
UPDATE:
I preserved the original version of the code but after some thoughts and thanks to some comments (thank you dear readers) I conclude that this example is not 100% correct. Before Thread.start() could be started the object has to be fully initialized and initialization will be completed only AFTER the SomeClass object is created. This way final keyword doesn't add any value there. On the other hand I meant this piece of code:

public class Main {
public static void main(String[] args) {
LinkedHashMap map = // map creation
// map initialization
final ExecutorService service = Executors.newFixedThreadPool(1);
service.submit(new SomeClass(map));
// etc.
}
}
In such case I'm pretty sure you cannot assume that e.g. second processor (in a multi-core platform) will wait before executing newly scheduled task until the object of class SomeClass is fully initialized, right? Correct me if I'm wrong because I feel have some mess in my brain now ;)
End of UPDATE

Whatever happens in the preProcessMap() method you can be sure that LinkedHashMap will be copied and preprocessed BEFORE starting the run() method by the new thread. This way any READ (get) operation on this map in all threads will be safe and will operate on completely and correctly initialized map object.

If only you remove final keyword from LinkedHashMap declaration you cannot be sure our previous assumption. It may happen that the thread will be started BEFORE copying the map and if in run() method you process this map in any way you may get NPE.

Let me use a bottle metaphor :) For me final keyword is like the guarantee that you closed the bottle of whisky before passing it to your crazy friend who likes juggling them. If you ensure that the bottle is closed (final) before passing it to your friend you can be sure he will not spill any of the precious whisky on the floor. On the other hand if you start passing the bottle to him while trying to close it you're not sure whether it's fully closed while he starts juggling it or not. It may be closed 100% of time when you meet in your place but when you go to your other friend's party he may spill very expensive whisky and break the bottle in the same time (test and production environments metaphor this time).
Conclusion? Close the bottle before giving it to anybody else.

I will not be original and simply copy Alex Miller's advice:
Final fields are ever so important and useful. Whenever possible, strive to make your fields final. One tip for this is to enable a Save Action in Eclipse (or your IDE of choice) that automatically attempts to make fields final if possible so you can’t forget!