
Lock-free programming for the masses - asb
http://kcsrk.info/ocaml/multicore/2016/06/11/lock-free/
======
BenoitP
> [...] 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](https://en.wikipedia.org/wiki/Double_compare-and-swap)

~~~
kcsrk
(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.

~~~
BenoitP
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.

------
GemG
Details on Multicore OCaml progress:
[https://ocaml.io/w/Multicore](https://ocaml.io/w/Multicore)

