About the service
I am an engineer in concurrent computing and have worked with the Occam language for many years, which grew out of Hoare's theory of communicating sequential processes. I typically receive one of two types of tasks. Either there is an old transputer system that still controls an installation, scanner, or test bench, and no one can figure out its code anymore. Or a new project is being planned where deadlock-free parallelism that can be proven correct is needed, rather than the usual tangle of threads and mutexes. I take on both kinds of work. For legacy systems, I read the Occam 2 source code, reconstruct the process network on paper, describe each channel and PAR and ALT constructs, and then either maintain operation on transputer emulators or rewrite the logic in occam-pi, in C with a CSP library, or into Go channels, preserving exact synchronization semantics. For new systems, I model everything as sequential processes communicating through typed channels, prove the absence of deadlocks and livelocks, and deliver clean, well-commented code with a test environment. A typical delivery includes a documented process map, working source code under version control, build and simulation, as well as a brief report on the concurrency model so your team can easily maintain it. Correctness is more important to me than clever tricks: channels remain unbuffered without good reason, ALT guards are checked, and shared state I design so that it simply doesn't exist. Whether I need to revive one stubborn transputer module or build a parallel simulation from scratch, I will see the work through from analysis to tested delivery. Describe what the system does, what hardware or runtime it runs on, and how much old code survived, and I will honestly assess the scope of work before we start.
