By Sung-Shik Jongmans
We see two major shifts in the last decade: increase in cores, and the move from waterfall to agile. Unit-testing become more widespread. However, what is still lacking is support for multithreading: the interaction between threads when they do their jobs. Assume two threads play chess. Each has its own local copy of the board. White makes a move on its local board, and communicates this to black. Black updates its local board, and makes its move, etc. This looks sequential, but the thinking part of the threads is of course parallel.
In our programming, we typically do not write the interaction code explicit. It is hidden in many different statements, as the program above shows. So, how do we unit-test this? Interaction-centric programming 😉 They propose a solution: as always, start with requirements, and write thread code in a GPL. To express the intentions of the threads, write a separate part in a separate DSL for high-level interactions. That gives normal code in GPL, interaction code in a DSL, and what they do is generate low-level interaction code combined with the GPL delivered by the developers. In the running example, this looks as follows:
The remaining problem is testing. Safety can be checked on the interaction code. However, liveness properties need to be check on the threads: behavioral contracts.
Question: how would we improve developers on learning to write such interactions?