The Brno C meeting brings cleanup and memory semantics together

Much of C's standards work concerns the exact meaning of operations programmers already perform. Releasing a resource, waiting on a condition variable, and ending an object's lifetime all need rules that a compiler and a programmer can interpret consistently. The August WG14 meeting in Brno provides a useful point to examine that work without treating every proposal as a finished language feature.

The WG14 meeting listing places the meeting on August 25 through 29. Hana Dusíková's April venue document identifies Mendel University in Brno as the location. The technical context comes from papers available before the meeting, which are a firmer basis for explaining design questions than inferring decisions from a meeting date.

The July preliminary agenda, N3635, lists work on undefined behavior and memory safety alongside a defer study group. It also names a C and C++ compatibility group. These are connected concerns, but they do not imply that all the work belongs in one revision of the core standard. The defer work, for example, has its own draft technical specification.

C was my first language, and I find this kind of semantic work more consequential than the number of new spellings in a draft. The language's practical value depends on a shared account of what its existing programs mean. Small wording changes can alter whether an interface's lifetime requirements are actually stated.

Condition variables need an account of ordering

Jens Gustedt's N3673 proposal makes one such gap concrete. It argues that condition-variable wording lacks a general account of how different calls interact. A wait operation affects both the condition variable and its associated mutex, while signaling operations may occur without holding that mutex. The specification needs to describe those relationships in the terminology of the memory model.

The paper proposes treating a condition variable as an atomic object with no directly observable value. Entering a wait call and returning from it become separate atomic operations. Those operations and signaling or broadcasting participate in the condition variable's modification order. The proposed memory ordering is at least as strong as relaxed ordering.

That last qualification is central to the design. Atomicity of operations on the condition variable is not itself a new general synchronization guarantee for application data. N3673 explicitly says synchronization comes from the described lock and unlock operations on the associated mutex. The proposal separates the ordering of condition-variable operations from the mechanism that establishes synchronization for the protected state.

This is a useful example of why memory-model vocabulary matters. Calling an operation atomic answers a particular question about its indivisibility and ordering. It does not answer every question about when writes made by one thread become visible to another. The paper attempts to put both answers in their appropriate parts of the interface description.

Destruction requires completion of waiting

N3673 also proposes explicit lifetime constraints. A condition variable must be initialized before ordinary operations, and destruction or direct modification of its representation leaves it unsuitable for those operations until initialization. This connects its library lifecycle to the language's account of indeterminate representations.

Before destruction, every wait operation on the condition variable must have returned to its calling thread. The paper calls out the case where another thread destroys the object while a thread remains blocked on it. That behavior is undefined under the proposed wording. A signal being issued is not the same event as the waiting thread having returned.

The distinction helps explain the actual ownership question. The thread that releases the condition variable needs a reason to know its users have finished the relevant operations. Merely observing an action that may cause progress does not establish that completion has happened. The proposal names the return of the wait operation as the required point.

N3673 is a proposal, so these paragraphs describe its intended rules. They do not claim that the Brno meeting adopted the wording. Its value as a public document is that it makes an existing specification problem concrete enough for implementers and users to evaluate.

Defer addresses another lifetime boundary

The preliminary agenda identifies N3589, revision 2 of the defer committee draft. That document proposes lexical cleanup for C. Reaching a defer statement activates a body that executes on the specified exits from its enclosing block. Multiple defers execute in reverse order within that block.

Its ordering of return values is particularly useful for understanding the design. The return expression and conversion occur before cleanup. A function can therefore compute a result using a resource and then release that resource while leaving the block. A deferred assignment to a local does not retroactively replace the result already computed for return.

The draft also restricts jumps involving deferred statements and jumps out of their bodies. Those restrictions are part of the semantics, not incidental syntax rules. A cleanup facility must specify whether control flow can bypass activation or enter a deferred body, because those possibilities determine which release operations run.

Condition-variable destruction and lexical cleanup thus expose related ownership questions at different levels. One proposal describes when concurrent use has finished. The other describes where release code runs on ordinary control-flow exits. Neither mechanism removes the need for the other kind of reasoning.

Papers and adopted wording have different roles

The Brno meeting belongs to continuing C2y work, with separate technical specifications developing beside it. A paper describes a proposed change and its rationale. An agenda establishes that a subject was scheduled. Neither, by itself, proves an adoption result or compiler implementation status.

I regard those distinctions as part of reading standards work accurately. The practical engineering content in the available papers is already substantial. N3673 identifies the completion event required before condition-variable destruction, while N3589 identifies the block exit and evaluation order that trigger cleanup. Those are precise lifetime relationships that can be discussed without turning a meeting into an unsupported list of newly available features.