The Java Specialists' Newsletter
Issue 1562008-02-26 Category: Concurrency Java version: 5+

Subscribe Free RSS Feed

Welcome to the 156th issue of The Java(tm) Specialists' Newsletter. Whilst my brother was enjoying beautiful spring weather in Germany last week, we were building a snow man at our house. Due to a freak of nature, we had about 2 millimeters of snow at the beginning of last week. This shut down all the schools in Crete for the day and all the civil servants took the day off. Having grown up in South Africa, I had never built a snowman before since the vital ingredient (snow) was missing. However, I went to a German school as a kid, and they taught us the theory of snowman building ;-)

The Master Course in Norway went so well that we are repeating it in April. In addition, we are running the Master Course in Tallinn, Estonia, from the 25th to the 28th of March 2008. We have more information on our website. Of course we also offer these courses in-house for your Java team.

The Law of Cretan Driving

We are looking at a series of laws to make sense of Java concurrency. Just to remind you, here they are again. In this newsletter, we will look at the Law of Cretan Driving.

1. The Law of the Sabotaged Doorbell
2. The Law of the Distracted Spearfisherman
3. The Law of the Overstocked Haberdashery
4. The Law of the Blind Spot
5. The Law of the Leaked Memo
6. The Law of the Corrupt Politician
7. The Law of the Micromanager
8. The Law of Cretan Driving
9. The Law of Sudden Riches
10. The Law of the Uneaten Spinach

The Law of Cretan Driving

After living here on the Island of Crete for sixteen months, we have come to appreciate the local residents. The Cretans are extremely hospitable and welcoming, once you have broken through the initial barrier. It is a charming and amazing place to raise your children.

Traffic in Crete takes some getting used to. It still amazes me when someone parks his car in the middle of traffic, puts the emergency lights on and then goes to buy a packet of cigarettes from the periptero (little store on the side of the road). No one hoots or complains. We just wait until he is finished and then carry on driving. The driver obviously needed cigarettes, so "what can you do?"

Most of the speed limit signs have bullet wounds or are covered with stickers advertising the latest concerts. From what I can tell, very few drivers even know the rules. Occasionally we have a visitor from a stricter country, who can then cause chaos on the roads by crawling along at the official speed limit. Not that we drive overly fast; the roads are rough on the car.

The majority of drivers fail to wear a seat belt, even though the law requires it. My American friend soon fitted in and drove without weating it. One day he was stopped by a policeman and slapped with a $500 fine! Of course we were all rather surprised. When rules are hardly ever enforced, we begin ignoring them. This can have painful consequences.

The Java Virtual Machine Specification was written with a large range of hardware architectures in mind. It is thus not surprising that it contains several rules that would usually not be enforced. However, if you break the rules, especially in concurrency, you might be surprised by a rather large fine one day. What makes this tricky is that even though your code might execute correctly on all the JVM implementations to date, you might still contain concurrency bugs that only show up on other architectures.

As Java Specialists, we should have read the Java Virtual Machine Specification and the Java Memory Model JSR 133 at least once. The Java Language Specification is also recommended reading for Java experts. (Now you have enough reading material to cure your insomnia...)

For example, here is an extract from the Java Memory Model:

"VM implementers are encouraged to avoid splitting their 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid this."

That is like saying: "Traffic police are encouraged to allow people to not wear seat belts, where possible. Drivers are encouraged to wear seat belts to avoid fines." The only way for the driver to be safe from fines would thus be to wear a seat belt all the time. However, the probability of a fine would still be so low that most of the time you would get away with breaking the law.

The Memory Model extract implies the following. Let's take the following code:

public class LongFields {
  private long value;
  public void set(long v) { value = v; }
  public long get()       { return value; }
}
  

If we call this method set() with values 0x12345678ABCD0000L and 0x1111111111111111L from two different threads, the value field could end up as 0x11111111ABCD0000L or 0x1234567811111111L.

If this happens in your code, it is a bug in your code, not in the JVM. I have not seen it happen in real life, since none of the JVMs that I used split the 64 bit values, to my knowledge.

Synchronize at the Right Places

Synchronization cannot be sprinkled around randomly. We need to synchronize in only the correct places, but nowhere else.

Too much synchronization causes contention. We can spot this when an increase in CPUs does not improve performance. See The Law of the Micromanager.

Not having enough synchronization leads to racing conditions and corrupt data. See The Law of the Corrupt Politician.

Fields might be written early if we try to avoid synchronization. See The Law of the Leaked Memo.

Changes to shared fields might not be visible. See The Law of the Blind Spot (formally named The Law of South African Crime).

Kind regards from Crete. I am planning an excursion tomorrow with a friend visiting me from South Africa. Hopefully we will be going to Balos tomorrow. Please let me know if you are planning to visit Crete so I can give you some good pointers on places worth visiting.

Heinz

Concurrency Articles Related Java Course