On Mon, Jan 23, 2023 at 10:54 PM Ian Lance Taylor wrote:
> There is a model of memory behavior in which programs use pure write
> memory barriers and pure read memory barriers. However, Go does not
> use that model. Go uses a different model, in which writers and
> readers are expected to
On Sun, Jan 22, 2023 at 11:36 PM Peter Rabbitson wrote:
>
> That's a fair point. I avoided going into details not to risk tickling latent
> design-urges of the readers ;)
>
> Setup:
> - Single-writer multiple-readers scenario
> - Writer is always exclusively single threaded, no concurrency
Just to be clear, to get what you want just write data normally for steps
1-4 and use an atomic store for step 5. That guarantees that other
processes will see steps 1-4 all done if they see the write from step
5. (But you *do* have to use an atomic read appropriate to your language to
do
On 1/23/23, Peter Rabbitson wrote:
...
> I guess I will spend some time to learn how to poke around the generated
> assembly tomorrow...
If I understand correctly you are trying to force your model of the
world into the Go memory model. The models are different, so this
won't work.
Please also
On Mon, Jan 23, 2023 at 7:04 AM Ian Lance Taylor wrote:
> Memory ordering only makes sense in terms of two different execution
> threads using shared memory. In order to answer your question
> precisely, you need to tell us what the process reading the memory
> region is going to do to access
On Sun, Jan 22, 2023 at 9:12 AM Peter Rabbitson wrote:
>
> On Sun, Jan 22, 2023 at 5:49 PM Ian Lance Taylor wrote:
>>
>> On Sat, Jan 21, 2023, 11:12 PM Peter Rabbitson (ribasushi)
>> wrote:
>>>
>>> This question is focused exclusively on the writer side.
>>
>>
>> Perhaps I misunderstand, but
On Mon, Jan 23, 2023 at 11:38 AM Robert Engels
wrote:
> The atomic functions force a memory barrier when atomically in conjunction
> with the atomic read of the same value.
>
> You could use CGO to call a C function to do what you desire - but it
> shouldn’t be necessary.
>
C doesn't solve this
The atomic functions force a memory barrier when atomically in conjunction with
the atomic read of the same value.
You could use CGO to call a C function to do what you desire - but it shouldn’t
be necessary.
Not sure what else I can tell you.
> On Jan 22, 2023, at 8:12 PM, Peter Rabbitson
On Mon, Jan 23, 2023 at 12:42 AM robert engels
wrote:
> Write data to memory mapped file/shared memory. Keep track of last written
> byte as new_length;
>
> Use atomic.StoreUint64(pointer to header.length, new_length);
>
>
This does not answer the question I posed, which boils down to:
How does
Write data to memory mapped file/shared memory. Keep track of last written byte
as new_length;
Use atomic.StoreUint64(pointer to header.length, new_length);
readers read header.length atomically to determine the last valid byte (using
whatever facilities their language has).
A reader then
On Sun, Jan 22, 2023 at 7:39 PM robert engels wrote:
> The atomic store will force a memory barrier - as long as the reader (in
> the other process) atomically reads the “new value”, all other writes prior
> will also be visible.
>
Could you translate this to specific go code? What would
The atomic store will force a memory barrier - as long as the reader (in the
other process) atomically reads the “new value”, all other writes prior will
also be visible.
BUT you can still have an inter-process race condition if you are updating the
same memory mapped file regions - and you
On Sun, Jan 22, 2023 at 5:49 PM Ian Lance Taylor wrote:
> On Sat, Jan 21, 2023, 11:12 PM Peter Rabbitson (ribasushi) <
> ribasu...@gmail.com> wrote:
>
>> This question is focused exclusively on the writer side.
>
>
> Perhaps I misunderstand, but it doesn't make sense to ask a question about
>
On Sat, Jan 21, 2023, 11:12 PM Peter Rabbitson (ribasushi) <
ribasu...@gmail.com> wrote:
> This question is focused exclusively on the writer side.
Perhaps I misunderstand, but it doesn't make sense to ask a question about
the memory model only about one side or the other. The memory model is
This question is focused exclusively on the writer side.
So are you saying that this will also work (based
on https://go.dev/play/p/ZXMg_Qq3ygF )
mmapBufRaw[fSize-1] = 255// W1
(*mmapBufAtomic.Load())[0] = 42 // W2
How about this, would that work as a "everything before
On the write side, you write your mult-GB data using normal writes, then
atomic.Store for the final flag uint. On the read side, you use an
atomic.Load for the flag uint followed by regular loads for the remaining
multi-GB of data.
Reading a particular flag value ensures that the following
On Sat, Jan 21, 2023 at 12:11 PM Peter Rabbitson (ribasushi) <
ribasu...@gmail.com> wrote:
> On Saturday, January 21, 2023 at 7:48:12 PM UTC+1 bse...@computer.org
> wrote:
> On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson
> wrote:
> Greetings,
>
> I am trying to understand the exact mechanics
( apologies for the previous mangled message, re-posting from a saner UI )
On Sat, Jan 21, 2023 at 7:47 PM burak serdar wrote:
>
>
> On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson
> wrote:
>
>> Greetings,
>>
>> I am trying to understand the exact mechanics of memory write ordering
>> from
On Saturday, January 21, 2023 at 7:48:12 PM UTC+1 bse...@computer.org wrote:
On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson wrote:
Greetings,
I am trying to understand the exact mechanics of memory write ordering from
within the same goroutine. I wrote a self-contained runnable example with
On Sat, Jan 21, 2023 at 10:36 AM Peter Rabbitson
wrote:
> Greetings,
>
> I am trying to understand the exact mechanics of memory write ordering
> from within the same goroutine. I wrote a self-contained runnable example
> with the question inlined here: https://go.dev/play/p/ZXMg_Qq3ygF and am
>
20 matches
Mail list logo
