Re: [Haskell-cafe] MVar considered harmful

Quoting Станислав Черничкин (2018-12-25 18:04:47)
>    >IIRC, MVars (in Haskell anyway) also have some fairness guarantees,
>    which I don't see otherwise mentioned in the discussion so far.
>    Looking at given mutex implementation I guess fairness controlled by
>    the primitive itself. More particular:�
>    1. Each thread which trying to obtain mutex will wait for one I-Var
>    exclusively (no competing threads waits shared I-Var hence there is no
>    space for �unfair� schedule).
>    2. I-Var�s swapped by atomic �getAndSet� which is likely can be
>    implemented over CAS or LL/SC and will be as fair as hardware could
>    be.�
>    > If the goal is to have a simpler base primitive on which to build,
>    everything has to boil down to compare-and-swap,
>    load-linked/store-conditional, etc
>    I had this discussion with a Cats guys, but I still can�t understand
>    how it�s possible to implement generic non-busy waiting with CAS/LL-SC
>    only. Ok, somewhere at deeper level it�s actually CAS/LL-SC,

> HLT (privileged instruction).

Right, so you have to build on primitives exposed by the OS instead. If
you've got userspace threads you can "block" by scheduling another
thread, if you have one, but indeed you can't not burn cpu cycles
without the OS.

>    Standing from this point, it�s worth to have some complete and
>    controversial (uncomposable) API at low level and having several
>    composable implementations over it with their restrictions.

How low level are we talking? My first instinct would be "just expose
whatever the OS and machine give you."

> (hence non-atomic unless acquisition consists of only one operation).

But takeMVar *is* only one operation. I'm not following the distinction?

-Ian