Simultaneous operation of a shared object needs an explicit control-arbitration rule

What it is

Two hands twist the same virtual screw, one clockwise, one not. Each person’s picture rotates its own way; on release the object jumps to whichever write arrived last. Floor control says in advance whose input counts on a simultaneous operation, what the other person sees, and how the handoff works. It is not who is allowed to touch the screw — that is admission. It is how a conflict ends once both already can.

Without arbitration, “doing it together” in space degrades into a write race.

Why it happens

A shared object has one authoritative state. Two inputs reach the host, or each other, at different times; the later overwrites the earlier, or both sides simulate and then reconcile. Either way, if the interface does not declare who is in control now, both people believe their rotation is happening and only discover the rewrite on release. The physical world composes two torques through collision and friction; a virtual object has no such mechanics, and must substitute a lock, a token, or a predictable merge.

Jitter is the surface; unclear responsibility is the root. People do not know whether to let go or twist again, so they race. A visible token (object highlighted as someone’s, others look-only) moves the conflict to the moment of reaching; an invisible token puts it after commit, where it is more expensive to repair.

Studying it

Paired simultaneous operation on one object, comparing no lock (last write wins), exclusive lock, soft lock (stealable after a countdown), and composed input (torques add). Watch conflict counts, completion time, and false reports of “I thought I was in control.”

Independent variables: arbitration policy, network latency, whether the object has a one-person semantics (a screw vs a board two people should lift). Dependent variables: repeated-steal count, undo count, task success, rated control.

Staggering the two hands by three seconds measures sequential operation, not arbitration. The inputs have to overlap in time.

Where it stops holding

Read-only sharing (looking at a model, one person demonstrating) does not need arbitration; an “in demonstration” mark is enough. Truly parallel objects (a board two people lift, a map both should scale) want composition, not exclusion; a hard lock turns collaboration into taking turns. Someone without permission never emits input — that is an admission failure, not a successful arbitration. At high latency, even a lock races with itself on acquire and release; it needs a leased timeout, not an exclusive that never drops.

Applying it

• Pick an arbitration per operable shared object: exclusive lock as the default for one-person parts, composition for objects that were meant to be forced together. Silent last-write is not a policy.
• Make the lock visible: holder highlighted, others told “so-and-so is operating this” when they reach, with wait or request-handoff.
• Locks must time out. Tracking loss or a drop must not freeze the object forever.
• How to check: have both people twist the same screw in the same second. Only one rotation should take, and the other should see the holder immediately. Both rotate and the object jumps on release: last-write is posing as collaboration.

Related

• Same group：N5.10.1 Avatar pose is the main cue to others' intent; without it, collaboration drops · N5.10.3 Network latency briefly desynchronizes how participants see the same object's state · N5.10.4 When devices of different capability share a room, the experience must align to the weakest · N5.10.5 Accuracy of pointing in a joint task depends on precise sync of participant positions
• Nearby：N5.05 Shared Space · N5.09 Spatial Anchors and Persistence
• Search terms：floor control · control arbitration · optimistic concurrency