Lock-free programming for the masses
kcsrk.info
kcsrk.info
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]
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.
> 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.