Memory Barriers with STM and MVar

Andrew Martin andrew.thaddeus at gmail.com
Mon Jun 3 15:34:12 UTC 2019


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/7a9e0a15/attachment.html>


More information about the Libraries mailing list