coding

Despite being a huge Mac fanboy (see the keyboard & mouse combo in the header pic), I use a PC running Windows XP at work. As such, I'm pretty used to bash-esque shells, and am continually frustrated by the Windows command-line being just that little bit different.

My build tree has been broken for a couple of days, and in the hope of saving it, I wanted to get rid of all the files that weren't part of version control. We use Perforce for version control, which handily makes all the files it manages read-only (requiring you to explicitly check them out to work on them). So all I needed to to was delete all the writable files in my source tree.

If I were on my Mac or a Linux machine, I might do some complex series of piped commands in a crazily complex script...before discovering a specific command that could do what I wanted. Being on Windows, I had to read up on the syntax for the del command.

Hooray! All I needed to do was:

del /Q /S /A-r *

Bingo!

This is probably quite obvious to any Windows peeps who use the command-line a lot. But heck, if I write about it here, I might remember the command next time.

One of the great things about coding is that there're always something new to learn: new techniques, new languages, and possibly most amusing of all, thousands of new ways to screw things up.

As a case in point, the other day, I wrote something a bit like the below:

I put this out for a code review (very useful practice - see The Joel Test), and within a few minutes, a colleague replied with the blunt, but informative "NO! You can't synchronize on a Boolean". Being an inquisitive sort, I enquired as to why, did some reading around, and messed with the code to break it.

Why This is Dumb

The assignment jobRunning = true effectively points jobRunning at a pre-created Boolean object representing a true value. This means that jobRunning is no longer the same object as it is when it is false.

To run this through, let's say a thread, T1 calls doJob() when jobRunning = false, then T2 subsequently calls doJob(). T1 will synchronize on jobRunning when it is false, then sets it to true. When T2 synchronizes on jobRunning, it will be a different object, so it won't be blocked, even when T1 is still in the synchronized block of code - the synchronized statement effectively does nothing for these first two calls, and we could end up with two threads running the main body of doJob() at the same time.

Quick Fix

This isn't a particularly difficult problem to fix, you just synchronize on a different object:

Not the most elegant of solutions, but pretty quick to implement in this case.

This is a fairly subtle consequence of the Java abstraction, and could have caused me a huge headache if it had gone unchecked - leaving one of those wonderfully annoying intermittent bugs floating around (the kind that take forever to track down and debug). So I figured it would be more than worth writing about, in the hope I might save someone else this trouble.

Bottom line: Don't synchronize on Booleans.