Hi Marc,

Let’s assume that I want to build an API to a distributed database as a
shopp system (sorry for that boring example — it is one with many
different requirements). Depending on my operation I have different
synchronization-needs.

If I put something into my shopping cart, I must know that the count of
available items is reduced for everyone before the next operation,
otherwise two people could reserve the same item. So I have to stop the
world and make sure every node on the database has seen my write before
the next operation.

If however I remove something from the shopping cart, it is not critical
that it is shown as available right-away.

And if I put in a code to get a reduced prize, the only synchronization
I need is to make sure that the next operation my node does for me has
seen this write (read *my* writes).

Finally the feedback I put into my order needs no synchronization at
all. It must eventually be stored, but no other node needs to coordinate
early to see it.

I hope this helps.

Best wishes,
Arne

Marc Nieper-Wißkirchen <xxxxxx@gmail.com> writes:

> Hi, Arne,
>
> could you explain what you mean using some fictional example?
>
> Thanks,
>
> Marc
>
> Am Do., 2. Sept. 2021 um 17:47 Uhr schrieb Dr. Arne Babenhauserheide <
> xxxxxx@web.de>:
>
>> Hi,
>>
>> Seeing the memory-order option got me thinking about more abstract
>> operations. When interfacing with a distributed system, orders like
>> read-your-writes and writes-follow-reads. For an onthology of such
>> orders, see
>>
>> https://jepsen.io/consistency
>>
>> When defining the API to a distributed system, atomic operations could
>> choose between different modes of access beyond the boundary of a single
>> CPU.
>>
>> Best wishes,
>> Arne
>> --
>> Unpolitisch sein
>> heißt politisch sein
>> ohne es zu merken
>>

--
Unpolitisch sein
heißt politisch sein
ohne es zu merken