Jay Lake's "Rocket Science"

Last time I checked, the list of people who had it in for me included Nazis, Commies, the Kansas City Mob, the United States Army, the Augusta Police and the Butler County Sheriff's Department. Not to mention Mr. Bellamy's gang, Doc Milliken and Lois. I was sure I'd left someone off the list, but I figured they'd let me know in due time.

—Rocket Science by Jay Lake.

I seldom read non-fiction, on the grounds that the Universe has a ≅14 billion year head start on me, and that leaves me with a lot to learn and not a lot of time to do it. But I've always had a soft spot for science fiction, and, months back, when an old friend, Jay Lake, sent me a link to a press release announcing that he'd just signed a contract for his second and third novels, my immediate reaction was "when did you have a first novel?" Let your friends move out of town, and little details like that start getting lost, apparently. He filled in the blanks for me, and I ordered a copy of Rocket Science immediately. I must admit, however, that I don't always enjoy Jay's writing. The skill and intelligence he brings to his craft are always evident, but the style and subject don't always appeal to me. Just a personal thing.

Jay and I met in 1986, working jobs that eventually payed about a buck over minimum wage. We were both in on the ground floor of the desktop publishing revolution, not that that meant a lot at the time. I was developing Mac software in my spare time and periodically interviewing for jobs in the Microcomputer Support Group in UT Austin's Computation Center. Jay was writing sporadically, and I can't remember what else. One thing about the kind of guy Jay was: with both of us basically living paycheck to paycheck, he was the sort of fellow who'd find our boss working herself up to firing me over one or another of my pointed critiques about the way our operation was run, and he'd tell her that I had a point, and if I was fired, he'd quit. Probably saved my job a couple of times that way. And I always had to hear about it from somebody else. You've got to respect a guy like that. And he was amazingly smart, had already lived a very odd life which gave him a fascinating perspective on things, and was a thoroughly nice guy. It's easy to end-up friends with a fellow like that.

So, an old friend like that gets his first novel published, and I think you pretty much have to go buy a copy and read it. And I'm glad I did. It was a hoot - the quickest read I've had in a long time. It's sci-fi set in post-World War II Kansas and centers around a mild-mannered fellow who quite unexpectedly crosses paths with a super-secret aircraft stolen from the Nazis right under the noses of Army Intelligence. Mayhem ensues. It's fun. Recommended.

---

Other recent-ish page-turners: The Soviet Space Race with Apollo, A World Lit Only By Fire, and Tales of a Shaman's Apprentice.

Conflating Atomicity with Thread-Safety

I've been adding a thread pool to Qwicap (in the unreleased version 1.4a40), and, with it, a lot of machinery for gathering information about the pool, the threads, the rate at which they're processing hits, etc. The thread pool implementation, of course, depends on careful use of synchronization for its correctness. Because synchronization can be costly, I tried to minimize its use in the information gathering machinery. I thought I had a lot of scope for such minimization due to the fact that operations on Java primitives that occupy 32 bits, or less, are atomic. So I did things like declaring various counters as "int" types and using the increment operator to change them, e.g. "ThreadCount++;", without bothering to execute them inside an appropriately synchronized block.

Very quick, but, during testing I soon realized that it was also very wrong.

A run of javap made the problem obvious. The "ThreadCount++;" statement, where "ThreadCount" is an instance variable, compiles into the following Java instructions:

   2:   getfield        #2; //Field ThreadCount:I
   5:   iconst_1
   6:   iadd
   7:   putfield        #2; //Field ThreadCount:I

Each of those instructions is operating on an integer primitive, and is therefore operating atomically, but, of course, there are four instructions, and if other threads are executing any of the same instructions at the same time, you can lose the effect of one or more of the increment operations. So, operations on 32-bit, and smaller, primitives are atomic in the JVM, but this fact does nothing to help you avoid synchronization.

My dim recollections of 68000 assembly language programming seem to have steered me in the wrong direction in this case, by leaving me convinced that an operation as simple and common as "ThreadCount++;" would probably be represented by a single instruction. Wrong. And returning to my 68000 documentation, I see that I must have been thinking of facilities like the "address register indirect post-increment" addressing mode, which was nifty, but also wouldn't have allowed that increment operation to be represented as a single 68000 instruction. Wrong again. That'll teach me.

By the way, am I the only old C programmer who wishes from time to time that the "asm" statement had been carried over into Java? I mean, once you have a platform independent assembly language, why not? I admit that the practical value would be low, and code readability would suffer, [OK, that's two good "why nots" right there] but I'd have found it very educational. Having actually used the JVM instruction set (which I wouldn't have been able to resist), rather than having merely read about it, I certainly would have known better than to believe that my increment operation would execute atomically.

Squirrels Return, So Does the Owl Cam'

I silently discontinued the owl cam' on Saturday, when I noticed that the fox squirrel family that had been living in the nest box had moved out. I was surprised they stayed as long as they did. However, cool weather this evening (Sunday) seems to have motivated them to return to the nest box, so I've fired-up the nest box cam' again. As before, my preferred view is the five-up, but you can choose from several options on the screech owl cam' main page.