Static-data serialization latency in concurrent COBOL execution

Short answer

A standards body should first focus on correctness failure rates, then on tail latency (p50/p99) and throughput scaling when the number of concurrent threads increases. Current compilers keep the single‑threaded semantics as the default and expose reentrancy or thread‑local storage through explicit compiler options or language extensions. A measurable latency increase that justifies changing the default would have to be proven in a realistic workload, and it would need to be balanced against the risk of silently breaking legacy programs that intentionally share state.

Correcting one premise first

The question assumes that the runtime “implicitly serializes” WORKING‑STORAGE. That is one possible implementation, but it is not universal. Many vendors document that concurrent access to non‑reentrant programs is undefined: you get data races and corrupted results, not a lock and a latency penalty. The ISO COBOL standard historically leaves multi‑threaded behavior largely implementation‑defined, so three outcomes are all in the field:

• Serialized access via runtime synchronization (latency, but correct results).
• No protection at all (fast, but incorrect under concurrency).
• Thread‑local or per‑invocation storage when compiled with a reentrancy/thread option (correct and fast, but different semantics).

Any standards evaluation must first verify which of these a given implementation actually does before debating defaults. Check your compiler’s documentation for the exact release – flags and defaults are version‑sensitive.

Metrics a standards body should prioritize

1. Correctness failure rate. Under N threads updating shared static data without reentrancy options, how often are results wrong? This dominates everything else: a default that silently corrupts is worse than one that serializes.
2. p50/p99 latency vs. thread count. Measure a minimal critical section (e.g., increment a shared counter in a tight loop) with and without the vendor’s thread/reentrancy option.
3. Throughput scaling against an embarrassingly parallel baseline. This separates synchronization cost from general runtime overhead.
4. Lock‑hold time and contention attribution. Use OS‑level tooling (e.g., perf lock events, vendor runtime tracing) to attribute latency to synchronization rather than guessing.
5. Opt‑in adoption rate. How often are real deployments compiled with the reentrancy option? A default change is only defensible if concurrent deployment is common while opt‑in usage is rare.

How implementations reconcile compatibility and performance

Across vendors the pattern is consistent: single‑threaded semantics remain the default; concurrency is explicit. Typical mechanisms include a THREAD compiler option, a THREAD-LOCAL-STORAGE section, or a RECURSIVE attribute that gives each invocation its own storage. This preserves legacy behavior exactly while letting concurrent workloads pay nothing for safety they didn’t ask for. The burden sits on the developer to know the deployment environment is multi‑threaded — precisely the gap a standards body would be evaluating.

Is the latency increase measurable enough to justify a default change?

If an implementation does serialize via a global lock, contention grows roughly with thread count and critical‑section frequency, so the increase is real and measurable. However, the magnitude is workload‑dependent, and no standardized cross‑vendor COBOL concurrency benchmark exists. Measure it yourself:

# Minimal experiment shape (pseudocode; adapt to your compiler)
# 1. Program with a WORKING-STORAGE counter updated in a tight loop.
# 2. Run under N = 1, 2, 4, 8, 16 threads, twice:
#    a) default compilation
#    b) with the vendor's THREAD/reentrancy option
# 3. Compare wall time AND result correctness for each run.

If (a) produces wrong counts, the issue is correctness, not latency, and the argument is about unsafe defaults rather than slow ones. If (a) is correct but slow while (b) scales, quantify the gap at your actual concurrency level before claiming justification. A defensible default‑change proposal needs both: representative benchmarks showing serialized access dominates end‑to‑end latency, and evidence that opt‑in reentrancy is rarely used despite concurrent deployment being common.

Practical recommendation

Standards work in this area tends toward explicit annotations rather than flipped defaults. Making static data thread‑local by default would change the semantics of code that deliberately shares state. The realistic near‑term outcome is clearer specification of what concurrent access to non‑reentrant WORKING‑STORAGE means (serialized vs. undefined), plus standardized reentrancy annotations — not a new default. Treat any cross‑vendor latency number you encounter with skepticism, and re‑verify behavior whenever the compiler version changes.