A send on a channel with capacity one has two outcomes and no third. Either the slot is empty, the value goes in, and the call returns immediately, and that caller holds the key [4]. Or the slot is full, and the goroutine parks on that channel's send queue until a receive frees it [4]. The holder's unlock is that receive [3], and the freed slot wakes the next blocked sender [5]. Nothing in the server schedules the winner, because the runtime already keeps a FIFO wait queue behind every channel [6]. There is no condition variable and no ready-queue bookkeeping to get wrong [8].
It is good craft, but the guarantee stops at the process boundary. Ordering exists because one process owns the channel for a given key, and the author's own framing is that there is no consensus layer to operate [1]. So the fairness is single-node fairness. Before it transfers to your workload, every contending client must reach the same process, and you must be content with a property the post itself hedges as "roughly in arrival order" [6], enforced by a scheduler rather than by anything you can assert in a test. Held against a Redis SETNX retry loop, where spinning callers get no ordering at all [7], the claim stands. Held against a replicated lock service, it is a different question, and the post does not take it up.
The more instructive half of the design is the part that concedes the elegant version is broken. A parked send is unreachable: it cannot be canceled, timed out, or withdrawn [9]. Two ordinary events need to reach it anyway, an operator reset on a key a crashed client still holds, and a client that drops its connection while queued [10]. Hence a second structure, a map keyed by request id, which the author is careful to describe as a cancellation registry and not the queue [11]. A `select` then offers the parked waiter three exits where the bare send offered one [12], and the third exit is fed by a per-connection goroutine that reads until EOF and cancels the context [13]. The server withdraws the request and answers nobody, returning `io.EOF` [14]. Omit that path and the queue fills with ghosts, each handed a lock it will never release [15].
The arithmetic of that safety is small and worth stating: one channel per key, one map entry per queued request, one watcher goroutine per connection [2]. Server memory tracks contention rather than keyspace, which is the right way round for a lock.
Durability is where the bill lands. The lock table lives in memory by default, so a restart, including every deploy, drops every key and never tells the clients holding them [16], and the post says two of them can then end up inside the same critical section [17]. The word "default" implies a persistence mode; the section supplied does not describe one. Until it does, I would run this where a double write to the protected resource is something I could detect after the fact, and I would drain contenders before shipping the lock server. Deploying a lock server under contention is its own critical section.
