When an operation is added to a queue, it moves through its own internal state, as discussed in Scheduling. Key transitions between these states are referred to as events, and for each event there is a dedicated observer protocol.

Observers are types which conform to these protocols and are attached to the operation. When an event occurs, all the operations which conform to the appropriate protocol are informed.

It is important to understand the purpose of both common observer prefixes, and the guarantees that the ProcedureKit framework makes:

• Will(X) observers are called before an event occurs.

Examples:

All "WillExecute" observers are called before the Procedure's execute() function runs.

All "WillFinish" observers are called before the Procedure's internal state transitions to finished.

• Did(X) observers are called at some point after an event occurs.

Example:

All "DidExecute" observers are called after the Procedure's execute() function returns.

However, other observers may be called prior to the "DidExecute" observer (depending on the order that events occur).

• An observer will never be called concurrently with other Procedure events (or observers) generated by a Procedure.

If you register multiple observers (for example: a DidExecute observer and a DidFinish observer) on a Procedure, they will not be called concurrently.

However, no such guarantee is made between Procedures. Hence, if you register an observer on ProcedureA and an observer on ProcedureB, both observers access/modify the same data, and both Procedures may execute concurrently, you should ensure that those accesses are thread-safe / support concurrency.