Memory Barriers with STM and MVar

[Carter Schonwald]

you could use the STM based sleep where the try to read an STMvar and then
retry to sleep until the write was done

if you only care about AMD64,
https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_multiprocessing_(SMP)_microprocessor_systems
,
you're probably not going to have the issues I think you're worrying about

other platforms, ehhhhh

On Mon, Jun 3, 2019 at 11:34 AM Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> After thinking about this more, it appears that a store-store barrier (not
> a store-load barrier) is actually sufficient for this. I just need to be
> sure that other threads see the writes to memory before the writes to the
> MVar (or before whatever STM writes to when atomically completes). However,
> I don't see any calls to write_barrier in the STM code or in the MVar code,
> so GHC may not currently provide the behavior I am looking for.
>
> On Sat, Jun 1, 2019 at 10:11 AM Andrew Martin <andrew.thaddeus at gmail.com>
> wrote:
>
>> What I'm doing is using STM (but it could be done with MVar instead) to
>> guard access to a rotating queue that is a large mmapped region of memory
>> (in my situation, it also happens to be backed by a file on disk). There
>> can only be one writer at a time. There can be many readers, but the
>> readers cannot read from the head of the queue if the writer is still
>> working on it. They must wait until the writer is finished. So, every
>> thread has the same base address and then they are all working at different
>> offsets into the queue. But when the writer tries to tell the readers "I'm
>> done writing to this area", how can I be sure that the readers will
>> actually see the writes to memory? That's the difficulty I'm having.
>>
>> On Sat, Jun 1, 2019 at 9:31 AM Elliot Cameron <eacameron at gmail.com>
>> wrote:
>>
>>> For my education, can you describe your use case a bit more? Using MVar
>>> as you did in your example seems like a strange use case. Normally you'd
>>> just put the pointer to the structure in the MVar itself.
>>>
>>
>>
>> --
>> -Andrew Thaddeus Martin
>>
>
>
> --
> -Andrew Thaddeus Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190603/c57e8e7c/attachment.html>