I mean that, instead of exposing atomic operations in the programming model (which are imperative constructs from the CPU to write to a memory location and require a notion of a memory model), the BPF virtual ISA could have just given you an ability to execute a series of high-level actions atomically or have them fail. It is basically a very small implementation of the ACI in ACID. This is only practical in this case because an eBPF program would need to be verified (by a trusted component; in this case the kernel verifier) before it can be executed anyway; any normal language with unverified, unrestricted semantics is too difficult to bolt transactions onto. You can just define a statically-determinable subset of programs that work and are accepted. This approach would have both upsides and downsides. The downsides include the need for more precise semantics, and an increase in verifier complexity (a lesser downside is an increase in compiler complexity to compile transactions to the underlying ISA; but I consider this 'lesser' because the verifier is more important, overall.) The upsides include a nicer programming model for users and independence from the underlying memory model in the processor, which gives you a lot of degrees of freedom to attack the problem.

I don't know what you would do in the case of like, livelock though. But I also don't know what the failure mode is if, say, the program I ran today always ran and hit some dynamic error, either e.g. in the case of livelock you have to eventually just kill the program to make any further forward progress, but this seems no different than if an eBPF program simply always failed due to dynamic constraints. If the program just keeps exploding you eventually have to back off... Another downside I guess is that it's probably hard to implement transactional models in raw RTL, like this project :)

But this is all just an idea. The thrust of it is to turn small exposures of the underlying processor semantics into higher-level compiler problems. I think this would work because you don't need to solve every compiler problem perfectly, just a small subset of them for a small set of domains. It doesn't really matter for Linux today because it just picked a common subset of the memory model for eBPF, but if anyone was to design a newer language for things like this in some new system, maybe some ideas like that are worthwhile. After all, CO-RE and related projects are about bringing "portability" to BPF programs. This is just an (somewhat logical) extension of that idea to the concurrent programming model. I don't need to worry about processor consistency models when I type "COMMIT TRANSACTION" in a SQL prompt, after all.

> To your second point about verification, yes this is something that is actively being worked on.

It's sort of hard to solve right now in the "Will this arbitrary C program work or not" sense, because the underlying toolchain and kernel implementation is evolving. I know there's a userspace verifier. What would be excellent is something like the ability to compile the kernel implementation of the verifier, but in userspace, so you could use it in CI. Does this already work, maybe?