Skip to content

feat(standard): reframe §3.2 concurrency as architecture-level concern — v1.30 #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
UnbreakableMJ merged 1 commit into from
Jun 24, 2026
Merged

feat(standard): reframe §3.2 concurrency as architecture-level concern — v1.30 #9

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 28 additions & 13 deletions The_Steelbore_Standard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,16 @@ concerns.

## Changelog

- **v1.30 (2026-06-24):** **§3.2** reframed — modern hardware
universally provides multi-core/multi-thread capability; harnessing
that concurrency is the primary performance lever. Concurrency is an
**architecture-level concern**, considered from the ground up
throughout design (not bolted on at implementation).
Adoption/abandonment conditions explicit: embrace concurrency where it
advances performance; abandon it where it degrades performance
(overhead, contention, serial workloads) or compromises Priority 1
(Stability). Compliance-checklist bullet revised.

- **v1.29 (2026-06-23):** Switch source of truth from GFM Markdown to
Texinfo: `The_Steelbore_Standard.texi` is now the canonical source;
`The_Steelbore_Standard.md` and `The_Steelbore_Standard.html` are
Expand Down Expand Up @@ -432,16 +442,20 @@ means of achieving it — but it is not the whole of Priority 1.**

## §3.2 — Priority 2: Performance

Performance is the foremost priority after stability. The default means
of achieving it is **multi-core, multi-thread concurrency** —
parallelism is the expected baseline, not an afterthought — *unless*
concurrency would materially degrade performance (synchronization
overhead, lock contention, or inherently serial / small workloads
outweighing the gains), in which case a simpler or serial approach must
be chosen and the trade-off documented.

- Concurrency must be **designed-in from the start**, never bolted on
retroactively.
Performance is the foremost priority after stability. Modern hardware
universally provides **multi-core, multi-thread** capability; harnessing
that concurrency is the primary means of achieving performance.
Concurrency is not an afterthought — it must be **considered from the
ground up**, throughout architecture design: data ownership, thread
boundaries, synchronization points, and parallelism opportunities must
be identified during design, not discovered during optimization.

Concurrency is adopted where it genuinely advances performance. It is
**abandoned** where it degrades performance (synchronization overhead,
lock contention, or inherently serial / small workloads) or where it
would compromise Priority 1 (Stability). When a serial or simpler
approach outperforms or is safer, it must be chosen and the trade-off
documented.

- Release builds should use CPU-optimized flags — `-march=native`, LTO,
PGO — **where the toolchain and target support them reliably.** Any
Expand Down Expand Up @@ -1245,9 +1259,10 @@ Before finalising **any** Spacecraft Software artifact, mentally verify:
- [ ] **§3.1** Stability: memory safety (Rust, or ASLR+CFI documented);
robust error handling, fault tolerance, and test-verified

- [ ] **§3.2** Performance: multi-core/multi-thread concurrency by
default (or serial trade-off documented); concurrency designed-in;
benchmarking before/after
- [ ] **§3.2** Performance: concurrency considered throughout
architecture design; adopted where it advances performance, abandoned
where it degrades performance or compromises Stability; serial
trade-off documented; benchmarking before/after

- [ ] **§3.3** Hardened security; PQC readiness addressed

Expand Down
48 changes: 32 additions & 16 deletions The_Steelbore_Standard.texi
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@
@setfilename The_Steelbore_Standard.info
@documentencoding UTF-8
@documentlanguage en
@settitle The Steelbore Standard 1.29
@settitle The Steelbore Standard 1.30
@c %**end of header

@set VERSION 1.29
@set UPDATED 2026-06-23
@set VERSION 1.30
@set UPDATED 2026-06-24
@set SUBDOMAIN https://Standard.SpacecraftSoftware.org/

@copying
Expand Down Expand Up @@ -106,6 +106,16 @@ are separate concerns.
@section Changelog
@itemize
@item
@strong{v1.30 (2026-06-24):} @strong{§3.2} reframed --- modern hardware
universally provides multi-core/multi-thread capability; harnessing that
concurrency is the primary performance lever. Concurrency is an
@strong{architecture-level concern}, considered from the ground up
throughout design (not bolted on at implementation).
Adoption/abandonment conditions explicit: embrace concurrency where it
advances performance; abandon it where it degrades performance (overhead,
contention, serial workloads) or compromises Priority 1 (Stability).
Compliance-checklist bullet revised.
@item
@strong{v1.29 (2026-06-23):} Switch source of truth from GFM Markdown to
Texinfo: @file{The_Steelbore_Standard.texi} is now the canonical source;
@file{The_Steelbore_Standard.md} and @file{The_Steelbore_Standard.html} are
Expand Down Expand Up @@ -640,19 +650,24 @@ not asserted by inspection alone.

@node Priority 2
@section §3.2 — Priority 2: Performance
Performance is the foremost priority after stability. The default means
of achieving it is @strong{multi-core, multi-thread concurrency} ---
parallelism is the expected baseline, not an afterthought ---
@emph{unless} concurrency would materially degrade performance
(synchronization overhead, lock contention, or inherently serial / small
workloads outweighing the gains), in which case a simpler or serial
approach must be chosen and the trade-off documented.
Performance is the foremost priority after stability. Modern hardware
universally provides @strong{multi-core, multi-thread} capability;
harnessing that concurrency is the primary means of achieving
performance. Concurrency is not an afterthought --- it must be
@strong{considered from the ground up}, throughout architecture design:
data ownership, thread boundaries, synchronization points, and
parallelism opportunities must be identified during design, not
discovered during optimization.

Concurrency is adopted where it genuinely advances performance. It is
@strong{abandoned} where it degrades performance (synchronization
overhead, lock contention, or inherently serial / small workloads) or
where it would compromise Priority 1 (Stability). When a serial or
simpler approach outperforms or is safer, it must be chosen and the
trade-off documented.

@itemize
@item
Concurrency must be @strong{designed-in from the start}, never bolted on
retroactively.
@item
Release builds should use CPU-optimized flags --- @code{-march=native},
LTO, PGO --- @strong{where the toolchain and target support them
reliably.} Any such flag known to break or destabilize builds on a given
Expand Down Expand Up @@ -2100,9 +2115,10 @@ explicitly renamed
☐ @strong{§3.1} Stability: memory safety (Rust, or ASLR+CFI documented);
robust error handling, fault tolerance, and test-verified
@item
☐ @strong{§3.2} Performance: multi-core/multi-thread concurrency by
default (or serial trade-off documented); concurrency designed-in;
benchmarking before/after
☐ @strong{§3.2} Performance: concurrency considered throughout
architecture design; adopted where it advances performance, abandoned
where it degrades performance or compromises Stability; serial
trade-off documented; benchmarking before/after
@item
☐ @strong{§3.3} Hardened security; PQC readiness addressed
@item
Expand Down
Loading