> [...] provide atomic operations on stacks and queues, such atomic operations cannot be combined into larger atomic operations

Questions aboud.

Is this about combining operations and then reducing them to a single atomic (read intel's TSX) primitive? Or is it about batching them together?

This is inspiring. Composability means so much more than just chaining things together. I believe type systems should carry way more information about orthogonal properties (can it block? is it associative, commutative? what does it want to be prefetched? does it contain locks? does it contain atomic operations?)

> represented as a k-CAS

If I understand correctly, the hardware has not been there yet for a few years now. Wikipedia lists a few unsucessful attempts [1]

[1] https://en.wikipedia.org/wiki/Double_compare-and-swap

(author here) The collected CAS operations are batched together using a lock-free k-CAS implementation. The library does not presuppose a hardware k-CAS mechanism.

The built up transactions carry around some information internally (blocking, # of CASes, etc). You could possibly extend the API to query them. But it is not clear to me immediately why you'd want to expose all of this info in the types.

Thanks for the clarifications.

> you'd want to expose all of this info in the types

This is a just a generic idea.

I meant the type system would let you express some property; and it would carry it to the rest of the program. In an IDE, you would have several views that would inform you of those properties. The "blocking" view would have color hints for: non_blocking, blocking_wait_IO, blocking_mutex, contention_on_X, etc; when this information is only in the documentation of the called elements.

Today, composing elements loses this information, when it could be carried with static analysis and sometimes some help.

Details on Multicore OCaml progress: https://ocaml.io/w/Multicore