Skip to content

Run the suite under a detector that reddens when a concurrency claim is broken #117

Description

@iderex

The record in #9 promises which calls may block, what a returned cancellation
guarantees, and what is safe to touch from two threads at once. #50 proves one of
those claims for image decoding and #64 proves three obligations behind the
drawing numbers. Targeted tests are the right way to prove each claim and they
are the wrong way to prove the absence of the defect, because a data race appears
on a machine with a different number of cores under a schedule nobody wrote and
passes ten thousand runs on the machine it was written on.

This is not a row in the parity table in #80. The gate this milestone is measured
against runs no such check and does not need one: it is one process on a server
under the runtime's own protection. This repository is a library hosted by up to
eleven applications whose concurrency models it does not choose, so the same
absence means something different here. The table records it as a check this
board adds rather than one it adopted, with that sentence as the reason, and the
milestone stays honest about parity being a floor and not a ceiling.

What this produces

Whatever the toolchain chosen in #11 offers for this, named rather than assumed,
since the options range from a first-class detector to a sanitiser that has to be
built for and to nothing at all. If the answer is nothing at all, that is written
down as an accepted risk with what it means, not left as an empty milestone row.

A second run of the same suite under it. On a pull request if the measured cost
allows, otherwise on a schedule with a stated rule for who reads a failure and
by when, because a scheduled red that nobody is named for is a red that stays.

A deliberate defect that the detector catches, kept as a test, so the run is
proven to bite rather than assumed to. A detector that reports nothing because it
was never actually enabled looks exactly like a clean tree.

A rule for a finding: fixed, or written down with the reason it is not, and never
suppressed without one. A suppression file with unexplained entries is how this
kind of run dies quietly.

Done when

The run exists and reports, a deliberately introduced race reddens it and is kept
as a test, its wall-clock cost is published with the command that measured it,
every suppression names its reason, and #80's table carries the row saying this
one was added rather than adopted. Blocked on #9, #11 and #16.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions