Concurrency Definitions Implemented

I just finished implementing concurrency definitions. This is an alternative view on external XML files, as explained previously: Instead of listing every class and method, and then saying what it may or may not do, concurrency definitions define a set of invariants, and then list methods and classes that must maintain those invariants.

I basically rotated the whole picture by 90 degrees, or to quote the example I used to explain the concept to my girlfriend:

Previously, I had a list of countries, and for each country, I’d say what someone does or does not do there. For example:

  • United States:
    • People drive on the right side of the road
    • People may not drink in public
    • People speak English natively
  • England
    • People don’t drive on the right side of the road
    • People may drink in public
    • People speak English natively
  • Germany
    • People drive on the right side of the road
    • People may drink in public
    • People don’t speak English natively

Note that these are all either-or properties; if someone drives on the right side of the road, then he implicitly doesn’t drive on the left side. That’s why I’ve listed some properties in italics; stating them isn’t necessary, because the opposite wasn’t said.

This is a very natural representation if you’re in a certain country and want to find out what somebody does or doesn’t do. However, if you’re compiling lists about these things, chances are it’s a whole lot easier to compile a list about driving, a list about drinking, and a list about speaking English, and then listing the countries in each category:

  • People drive on the right side of the road:
    • United States
    • Germany
  • People may drink in public:
    • England
    • Germany
  • People speak English natively:
    • United States
    • England

I claim this list is easier to compile, because you have to think about just one thing, and then go through the list countries. In the other, original approach you would enumerate the countries, and then try to list every property you can come up with.

The original approach (I describe it as class-based or <threadcheck> approach) was well-suited for instrumenting class files, because the instrumentor was basically a traveler through all the classes and methods, and what the instrumentor wanted to know was “what can I do here?” I therefore don’t regret writing it that way, and in fact, it’s still written that way. It’s just a much more efficient format.

However, when I look at the current Java API annotations, then I don’t get a clear picture of what may be done and what may not be done. I just don’t see the categories, the invariants. All I see again are classes and methods, and that brings us back to the original problem: The boundaries between classes are not the same as the boundaries between threads.

I just converted the same annotations in the XML file shown in the other poast from the old format to the new format (I call it as concurrency definition-based or <threadcheckLdef> approach), and I must say I find it significantly easier to understand:





















































































than the old XML file (reproduced here for your enjoyment):





































































































































































































In the newer version, I can clearly see the three different invariants I’m using. I had no idea what I’d been using in the old one, without actually going through it line by line.

Making this happen caused a major refactoring that touched the XML configuration library and loading external XML annotations. I factored out most common code, and now it is even possible to convert one XML representation into the other and back, and to merge them while eliminating overlap. Annotations can now also be printed out just like Java code, which helps a lot in generating human-readable output.

My MacBook has been silently working on a remote backup to my server’s backup drive for, oh, 8 hours now, and it’s only half done. I should have plugged in the Ethernet cable first.

I’m cautiously optimistic about my health. Yesterday and today I haven’t had to cough very much anymore, and there was hardly any mucus. Both times when I got up I had a horrible muscle cramp in my lower right leg, though, one that made me scream out loud (“sol”, like “lol”?). After stretching a bit, I limped into the bathroom and took a hot bath.

I also made a bunch of backups in the past days and finished a small home-improvement project: I finally connected the line-out of my media server to the stereo in my bedroom. The sound quality has improved remarkably when not only my two small computer speakers are playing. I ran the speaker wire up in the corner of the walls, along the edge of the ceiling, and then through the air conditioning duct. Most of it is hidden.

Of course, it’s not as fancy or functional as a Squeezebox, but I did this for about a tenth of the price.

It’s 9 AM now, I need to go to bed. I think I’ll let my MacBook finish its backup. Good night/morning.

Share

About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing, Uncategorized. Bookmark the permalink.

Leave a Reply