JMM: Constructors don’t have visiblity/reordering problems

April 2, 2008

One of the things that has been bugging me for some time is this: do I need to prevent visibility/reordering problems inside my constructor. With normal methods it is quite clear if there are visibility problems, eg:

class Foo{

	int a=0

	void init(){
		a=1;
	} 

	void print(){
		println("a="+a);
	}
}

If the init method is called by some thread, others threads don’t need to see the newest value of a (ever). This problem can easily be prevented by making a volatile or doing read/write of a inside a synchronized block(there are more ways). But constructors are a different story, because the reference to the newly created Foo instance, needs to be published safely before other threads are able to read fields of that instance.

class Foo{
	int a;

	Foo(){
		a=1;
	}

	void print(){
		println("a="+a);
	}
}

//safe publication
volatile Foo foo = new Foo();

This safe publication acts as the missing link to make ‘piggybacking on synchronization’ possible; so even though the newly created object(s) still has visibility/reordering problems, after the safe publication has been executed, all other threads will see a correctly constructed object when they read foo. It is very important to realise this will only work with a safe publication, otherwise there will be problems.

So from a technical point of view there are no issues. The question is if this is a correct way to deal with this situation. Personally I prefer to remove all jmm issues inside the constructor (in 99% of the cases by making the fields final) so it removes any doubt how this class is going to behave regarding jmm. When I inspect code being used by multiple threads, one of the first things I look at are the fields and the constructors. If there are jmm ‘problems’ inside the constructor, it is likely that others methods have problems as well.

ps:
Last year I wrote a blogpost about the Spring container providing a safe publication, you can check it here.


Code Quality: Care about your name

January 27, 2008

One of the things most of us encounter from time to time is bad naming in source-code. It could be a package, interface, class, method or variable, but when you have it in your system, it can irritate, or cause more serious problems like code duplication (DRY) and perhaps slowing you down. Even worse is a class with a misguiding name because people are put on the wrong foot, especially when they are new or not touching the code regularly.

That is why I take a step back and see if the name is intent revealing. In some cases a better name is found later (throw it in the team). And with all the refactoring support in new IDE’s, renaming almost always is not a issue and should be picked up asap. Especially when its a leaf in the system (something deep down) I do it immediately to reduce technical debt.

When the concept the name represents, for example a Listener, is used more than once in your system, make sure it is used consistently so you know what to expect. According to the timeless Unix philosophy this is called: ‘The rule of least surprise’. In some cases a good name depends on knowledge (e.g. perhaps you know it as an some kind of pattern), so a good name can be subjective. When it could be unclear to others, I add it to the documentation.