Tuesday, April 17, 2007

Lock-Free Hash Tables

I forgot to post about this at the time. Cliff Click gave a talk about his lock-free hashtable at Google; it is definitely worth a peek. Available here.

There is a very funny thread on the concurrency-interest mailing list this week about "lock-free mania". Apparently, software engineers are going to start choosing "trendy" lock-free data structures for no valid reason, resulting in lots of fragile code. In related news, recursion, memoization and every data structure more complicated than a hash table just started laughing their arses off. B+ Trees were quoted as saying, "I can't count the number of times some database-implementing hack has thrown together a cheap and poorly tested implementation of me because he thinks it is 'trendy' to put together an indexing mechanism. Oh, wait. Zero is a number. Never mind!"

In all seriousness, I have actually stopped someone from using a lock-free algorithm where a lock would have been more readable, and had the same performance impact. So, as with every other programming technique on the planet, you have to be careful about where you use it.

Personally, I see the complexity of lock-free algorithms as a hack that just needs to hold us over until hardware atomicity is supported for more than 1 word at a time. I actually asked Cliff about this in the talk, because he controls his hardware (I start laughing, he stares at me for a bit, and then I ask that question, which was not the question I was imagining.) He only did it in the way he did because he wanted his hash table to be useful for other Java implementations. That's community spirit for you!

Tuesday, April 10, 2007


Okay, so I lied about the contents of my next post. I bet no one even notices. Anyone even reading these? Yeah, right.

I was asked a question about fairness. The notion of fairness is one where there are some number of individual entities trying to make progress (in our case, threads), and there is some level of guarantee that this will actually happen.

Java has no meaningful fairness guarantee. A Java virtual machine is allowed to let a thread hog all of the CPU time. If I have:

Thread 1:
while (true);

Thread 2:
System.out.println("Hi there!");

There is no guarantee that Thread 2 will actually ever print its message. This is so that Java implementors can create cooperative implementations, where context switching only happens when Thread.yield is called, or when blocking occurs.

(In point of fact, this applies almost exclusively to the Oracle Java server. The popular VM implementations from Sun and IBM are preemptive.)

You could even have a wait loop:

Thread 1:
while (!someBoolean) {
  try { wait(); } catch (InterruptedException e) {}

Thread 2:
someBoolean = true;

This might not even terminate, because wait() can wake up spuriously. The wait loop can sleep and wake up indefinitely, and never let the other thread proceed.

At some point, I will explain what this has to do with the Java memory model.