Archive

Archive for the ‘concurrency’ Category

Why Java? … or … why not C++?

November 24th, 2008 No comments

In a recent meeting I was asked whether Java’s concurrency support was an advantage for jsoar over the existing C++ implementation. I kind of said yes, but was mostly incoherent because I’m always trying to avoid saying things that aren’t true.  This is probably a weakness. Anyway, I wrote the followup email below and I kind of liked it so I figured I’d post it … just for context, “kernel” here refers to the Soar kernel …

Regarding Java concurrency support vs. C/C++… In any discussion like this, you can argue than anything is possible in just about any language which is why I was a little hesitant to make a firm statement. In this case, C++ (or at least its runtime libraries) provide the same basic concurrency primitives as Java, i.e. locks, condition variables, etc. However, Java has two advantages here. First is cross-platform support. The Java concurrency and memory model are specifications that are implemented the same on every platform. So
while it’s possible to write a wrapper library that puts a common interface around say pthreads and the Win32 threading APIs, guaranteeing consistent semantics across both is notoriously difficult (e.g. http://www.cs.wustl.edu/~schmidt/win32-cv-1.html).

Boost and other libraries will cover many things, but you’re still left having to include the boost library and hoping that it plays nicely with whatever threading model any other library your using decides to use.

Furthermore, on top of the basic synchronization primitives, Java provides a really nice library of higher-level concurrency tools (http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html) like concurrent collections, thread-safe queues, thread pools, etc.  All of these can be implemented with pthreads, but it’s nice to have a standard set of tools that are used more or less uniformly throughout the community. The situation is similar to the mid-90s C++ where everybody and their grandma had their own implementation of a string class because a standard hadn’t yet been established.

More generally, since I’ve been thinking about this quite a bit lately for some reason, the advantages of Java over C/C++ boil down to the following:

  • Managed execution with garbage collection. I know Bob and Jon are dreading porting the new waterfall back to C where they’re going tohave to start reference counting symbols again
  • Far superior tools. Setting aside the complexity of C++ itself, as long as there’s a pre-processor, you’ll never have refactoring, or even browsing, tools that you can really trust. Not to mention accurate code completion, etc. This is where I personally see a 5-10x productivity gain over C++ and I consider myself a pretty knowledgeable C++ programmer.
  • More flexible run-time architecture. The fact that I can just add another main() to a code base for testing without creating another project is great, not to mention the ability to drop a library on the class path and load it reflectively. Of course, this can be done in C++ with DLLs, but with all of the requisite cross-platform baggage, not to mention issues with memory management when each DLL may have its own heap, compiler support for exceptions across DLL boundaries, binary compatibility issues, etc.
  • Superior testing tools. cppunit works, but again, because of the run-time stuff above, you write as much boilerplate as actual test code and integration with the development environment is limited.

The more I’ve thought about this, the cute stuff like scripting language support, running in Java application servers, and even concurrency falls away. They’re all nice, but also possible with the Soar’s SML Java (or C#, Python, etc) bindings (maybe with some tweaking).  So you’re left with the fact that development and testing on the kernel itself (and surrounding modules) is where Java really wins out.  If you want to do research on the kernel itself, it helps to not spend half of your time waiting for builds to finish, hunting through headers, or creating cross-platform wrappers for basic services.

Also, this isn’t really about Java. If jsoar was a completely personal project for me (i.e. I didn’t work at SoarTech), I’d probably try it in C#, which seems to be both mainstream (as opposed to other advanced
languages like F#, Scala, etc) and ahead of Java in cool language features. It’s more about productivity in C++ versus almost any other language out there.

Categories: c++, concurrency, java, soar Tags: ,

Concurrency – A paper and a war story

December 7th, 2007 No comments

Today I came across two nicely related blog posts. In the first, Alexander Schatten gives excerpts from a paper (PDF) detailing what a lot of people have a sneaking suspicion about: getting concurrency right is really really tricky, even if you know what you’re doing. I’m glad the paper discusses listeners in a multi-threaded environment because every deadlock I’ve had lately seems to involve listeners being invoked while a lock is held.

In the second blog post, Marc relates a great war story where he channels Gene Kranz from Apollo 13: “Let’s work the problem people. Let’s not make things worse by guessing”. It’s really a textbook example of systematically understanding and working through a problem. In relation to concurrency, the problem he tracks down and fixes is a perfect example of how tricky multi-threading can be.

Categories: concurrency Tags:

Name Your Syncrhonization Objects

November 12th, 2007 No comments

A not-used-enough feature of Java is the ability to set the name of a thread. Simply pass the name to the thread’s constructor, or call the Thread.setName() method. The nice thing about this is that when you’re looking at the thread list in a debugger, the names of the threads will be displayed rather than some random identifier generated by the JVM or debugger. This is a boon for sanity. But what about synchronization objects?

As Joshua Bloch recommends in Effective Java, it’s a good idea to favor the private lock object idiom over the more typical practice of sprinkling your methods with synchronized keywords. Now, most examples you’ll find just create a new Object for the private lock:

   private Object lock = new Object();

That’s fine, but some debuggers, especially Eclipse will also show the locks that each thread holds and which lock they’re waiting for. If you just use a plain old Object, the debugger’s output won’t be very descriptive. Since the debugger just uses the toString() method to display the lock object, we could just use that to give the lock a name. I wish their was an object with the toString() method already implemented…

   private Object lock = new String("My Lock");

The important thing here is to make sure you create a NEW string instance. If you just use a string literal, it will be taken from the string pool and, if you’re unlucky, your lock may get used and possibly locked by someone else. Not very private.

Anyway, the result is nice, readable lock names that really help when tracking down deadlocks.

Categories: concurrency Tags: