Fixed That One

Randall Scarberry displays the joys of shared memory concurrency in this article on Java...

At some point while reading this, you've probably wondered about what synchronization issues might be encountered in SMT adaptation. I encountered two with ConcurrentKMeans, both in the nested class ProtoCluster, which is a class K-means uses to track intermediate clustering results. It was clear to me that something was wrong, because ConcurrentKMeans gave results different from BasicKMeans even though it was using the same N, K, and random seed. I ran it several times, occasionally getting an ArrayIndexOutOfBoundsException originating from the ProtoCluster method add(int ndx). Then the obvious dawned on me: multiple threads were calling an unsynchronized method. (Doh!) The exception happened because one worker thread attempted to add a coordinate, while another thread was expanding the array holding the coordinate indices. Simply adding the synchronized modifier to the add(int ndx) method definition fixed the problem.

OK, fixed *that* one. Any confidence that was the last one?

Not that concurrency is easy, but almost all programming languages exacerbate this with extremely outdated memory and concurrency models.

Don't you just love exacerbation?

Eventually we'll all move to shared-nothing languages of one stripe or another to implement concurrency, Erlang being one. Along the way we'll move to better shared nothing mechanisms for our current languages rather than threads, monitors, and such, spaces being one.