OS without mutexes and semaphores is possible
Yup, it's possible. There are several ways to solve the problem, as well as constraints and complexity.
- Sequential consistency -> good for implementers and programmers but offers low performance
- total store ordering (aka TSO, RISC-V RVWMO) works great for programmers, hard for implementers
- Like IBM POWER way or like Nvidia GPUs way -> simple for implementers, Hard for programmers
- Other ways ... ?
Yup, there are several memory consistency models(1), a wide range of memory models, as well as there is a big cliff with IBM and Nvidia called "
multi-copy-atomicity"
Anyway, the pipeline of machines like POWER10 and PowerPC is full of problems regarding the synchronization; RISC-V has some interesting approaches (from
Weak Memory Ordering RVWMO, to extensions like
Zam and
Ztso), all interesting and they make life simpler for the software programmer (a nightwear for the HDL designer), but personally I am researching on "
transaction memory consistency model"(2).
All of this, because I prefer Mutexes and Semaphores, but also monitors if the language can give an hand on them.
(1) wait, what is "
memory consistency model"
?
Well, something that at least specifies the values that can be returned by loads during concurrency . Mutexes and Semaphores are both sensible to this.
(2) wait, and what is "
transaction memory consistency model ?
Well, it's like (1), but it also specifies what is permitted and what is forbidden(3), the order, and how loads are presented to other units. Basically it adds metadata and time-constraints to the hardware units used to implement Mutexes and Semaphores
(3) wait, what?
An implementation can do anything it wants under the covers, as long as the load return values satisfy RVWMO, so implementations can speculate past a lot of these rules, as long as they make sure to, e.g., squash and replay whenever the violation might actually become observable
At ISA level there are two common modeling approaches:
axiomatic, which defines a set of criteria to be satisfied, and
operational, which defines a "
golden holy abstract machine model" where some executions are forbidden unless producible when executing this model.
I am with the "operational approach" because it offers less of gray area and obscure code this way.