Structures

SharedMap

The ranger creates a field record with a gate-status key. Alice and Bob write different values before either update is delivered to the other hikers.

The station log decides the key

A SharedMap gives every accepted operation a sequence number. When two writes target the same key, the greater sequence number determines the value.

SequenceWriteVisible value
SN 1Alice · Trail openTrail open
SN 2Bob · Trail closedTrail closed
The server order is the conflict rule, not a timestamp in the value.

Three field maps

Sequence two writes to one key

Alice and Bob edit gate-status inside one delay window. The ranger's numbered stream selects Bob's later operation.

Conflict rule Use the greatest server sequence number per key.

Alice

Empty map

No entries

Map-edit slip gate-status: Trail open sequence number assigned at ranger station

Bob

Empty map

No entries

Map-edit slip gate-status: Trail closed sequence number assigned at ranger station

Carol

Empty map

No entries

Map-edit slip No slip in this race Carol observes delivery

Ranger sequencer Server order selects writes 0 operations shared

Mechanism evidenceNo race delivered yet.

  1. No operations shared yet.

Enable JavaScript to run the demo. The race and expected result remain in the lesson.

Run the authored race, or let any hiker edit a local map.

One value survives

The rule is simple and useful, but the losing value disappears. If offline clocks should choose the winner, use LWWMap. If a concurrent update must survive deletion, use OR-map.

Sources and implementation

The demo runs Watershed's SharedMap kernel through a three-client Sluice room.