I just contemplated one of the basic problems of concurrent programming: The “contours” of the concurrent program, the different threads, usually don’t conform to the “contours” of the object-oriented programming language. There may be one class, and a hierarchy underneath it, and a second class with its hierarchy, but threads can and often do cut completely across object-oriented boundaries. That’s why it’s so hard to separate things out and specify what should only be run in one thread.
My project can definitely help. However, I just realized that there might be a specialization of my work that can help even better: In addition to providing a class definition, like Java already does, and perhaps adding thread annotations to it, I can provide a concurrency definition that specifies what gets executed in what thread. It’s basically an inverted XML file that I have used so far.
The XML files so far were based on the packages and classes, just like class definitions. A concurrency definition would do it the other way around, it would be based on the invariants and list packages and classes.
Consider, for example, the following XML file from this post, which specifies simple invariants:
The concurrency definition as an XML file would look like this:
It merely lists all the invariants, and then the classes and methods that belong to it. That way, there should be a clear delineation between what is part of one thread (or rather: one invariant) and what isn’t. This would be in addition to the class definitions. Of course, internally, these XML files would be translated into the regular annotations.
I’m intrigued. The question now is whether I’m gonna interrupt my writing to program this.
