EEZ Studio TestAndSet: Make Every Exit Release the Flow Gate

EEZ Studio TestAndSet can guard a section of Flow with a Boolean variable. Its most important design question is often not how to enter the section, but how every valid owner leaves it. A gate that remains true after an early exit can make later requests wait indefinitely, even though the visible work appears finished.

The TestAndSet documentation describes waiting while the variable is true, setting it true when it is false and then continuing through seqout. It also instructs the Flow to reset the variable on exit. The pinned implementation performs that Boolean check and assignment, or requeues the component to try again.

The code reference is framework commit dc9af2d5004201d6c31273a4c4fcfe27fc20c234, inspected separately from EEZ Studio v0.29.0. Confirm the actual generated runtime before applying implementation details. This is standard EEZ Flow behavior, not a claim about Flow Lite or native operating-system locks.

Draw the ownership interval

Place the gate before the work that must not overlap, and identify the exact point at which the current operation has finished using the protected resource. The ownership interval begins only after TestAndSet acquires the false gate and continues through seqout. It does not begin merely because a request reached the waiting action.

That distinction prevents a dangerous cleanup mistake. A request that failed before acquisition should not clear a Boolean owned by another operation. Likewise, a waiting request should not release the gate because its own UI was dismissed. Release belongs to the operation that successfully acquired it.

If the work includes an asynchronous native operation, decide whether ownership lasts until the request is submitted or until that operation completes. Releasing immediately after submission may allow the next request to overlap work that the design intended to serialize. The correct boundary depends on the resource contract.

Audit every exit from the guarded section

Trace the normal completion path first. Then enumerate early return, rejected input, cancellation and error paths that can occur after acquisition. Each needs a deliberate release policy. A cleanup node that exists somewhere on the diagram is not enough if one branch bypasses it.

A common design is to route supported post-acquisition exits through one cleanup section that clears the gate, then reports the outcome. This is a design pattern to implement and test, not an automatic finally construct supplied by TestAndSet. An unhandled failure that stops the relevant Flow may never reach that node.

Do not assume that adding a local error output catches every possible failure in downstream or native work. Identify the error mechanisms the integration actually uses and verify that the intended owner can release or recover the gate. If a whole runtime stops, recovery may belong to lifecycle initialization rather than an ordinary Flow branch.

Use a two-request diagnostic

Replace real side effects with a harmless diagnostic operation. Submit request A and hold it inside the protected section. Submit request B while the gate is true. Record gate state, acquisition and release observations with request identities.

The expected design is that B does not enter the protected work until A releases it. Then repeat with A taking each supported early-exit path. The test should show both exclusion and eventual release; a test that only confirms B waits can accidentally approve a permanently stuck gate.

Also repeat a request after normal completion. A stale true value becomes obvious when the next request cannot proceed. Test initialization explicitly so a restored or incorrectly initialized Boolean does not begin the application in a blocked state.

Waiting does not supply a scheduling policy

The cited implementation requeues while the gate is true. That observation does not establish fairness among multiple waiters, a maximum waiting time or a cancellation protocol. Do not describe the Boolean gate as a full request queue with those guarantees.

If the product needs a timeout, define what timing out means and which request owns any cleanup. Clearing a shared gate simply because a waiter has waited too long can violate exclusion while the original owner is still active. A timeout policy must account for ownership, not just elapsed time.

Similarly, the documentation's atomic description concerns the Flow operation. It should not be expanded into a guarantee that native threads or interrupt handlers can access the same state safely without appropriate synchronization. Keep cross-thread resource protection in the native integration's own contract.

Validate the variable and the recovery rule

The inspected implementation requires an assignable Boolean value and rejects a non-Boolean destination. Use an explicit Boolean gate with a documented initial state. Avoid treating an unrelated status integer as interchangeable just because zero and one look familiar.

Finally, state how the system recovers if the owner cannot finish. That may require a product-specific cancellation or reinitialization procedure; TestAndSet alone does not provide one. The procedure must avoid releasing a resource that is still in use.

No concurrent Flow or hardware experiment was run here. The proposed audit turns a simple Boolean guard into an observable ownership protocol: acquire once, protect the intended interval and release on every supported owner exit.