Blog › ICP guides

Oz developer on retainer: Mozart platform programming, dataflow variable synchronization, concurrent constraint programming, and Oz language on monthly retainer

October 1, 2026 · ~15 min read

An Oz developer was using single-assignment dataflow variables as synchronization primitives in a concurrent system on the Mozart platform. The pattern was: bind a variable V in one thread (V = compute()), and read it in a second thread (process(V)). The second thread would suspend on V until the first thread bound it, then automatically resume. The developer introduced a typo while extending the code: in the reading thread, the variable name was misspelled as Va instead of V. In Oz, any capitalized identifier that has not been declared is an implicitly introduced fresh unbound dataflow variable. Va is a fresh variable with no relationship to V. The second thread called process(Va) and suspended waiting for Va to be bound. Nothing in the program ever bound Va. Thread 2 suspended indefinitely. Wrong variable bindings: 1. Fix: corrected the identifier from Va to V. process(V) now waits for the correct variable, which is bound by thread 1’s V = compute(). Thread 2 resumes when thread 1 completes. Wrong variable bindings: 1 → 0.

The work log said “fixed thread synchronization issue, corrected variable reference, 6h.” It cannot explain the mechanism: that Oz’s implicit variable introduction means that a misspelled variable name is a silently valid program that introduces a fresh unbound variable rather than a compile-time scope error, that a thread that reads an unbound variable suspends rather than raising an error, that the suspension is indefinite when no other thread ever binds the variable, or that diagnosing the issue required understanding which variable each thread was waiting on, tracing the binding and reading of each variable across threads, and confirming that the intended synchronization variable and the actual waiting variable were two different identifiers. A client reading that entry sees six hours for what sounds like fixing a typo. What is invisible is the diagnostic cost: Oz does not report an error for an unbound variable used as a function argument; the thread simply suspends; identifying the suspended thread, tracing what it was waiting on, verifying that the bound variable (V) and the waited variable (Va) were different identifiers (not the same variable in different binding states), and confirming that the fix established the correct synchronization relationship.

Oz language overview: multi-paradigm concurrent programming on the Mozart platform

Oz was designed by Gert Smolka and collaborators at DFKI (Deutsches Forschungszentrum für Künstliche Intelligenz) and Saarland University starting around 1991. The Mozart platform is the implementation of Oz: a virtual machine, standard library, and development environment for Oz programs. Oz was designed as a multi-paradigm language that unifies functional programming, object-oriented programming, concurrent programming, and constraint programming in a single coherent model based on single-assignment variables (dataflow variables) and concurrent threads.

The core semantic foundation of Oz is the computational model based on single-assignment variables and threads. Every variable in Oz (capitalized identifiers are variables) is introduced as an unbound dataflow variable. The first binding of a variable (X = value) is permanent: subsequent bindings to the same value are unification (and succeed), while bindings to a different value are errors. A thread that attempts to read an unbound variable suspends until another thread binds it. This model provides a form of deterministic concurrency for programs that use dataflow variables as synchronization tokens: the execution order of operations that depend on dataflow variables is determined by the order of bindings, not by the order of thread scheduling.

Mozart runs on Linux, macOS, and Windows. Oz programs are typically developed using the OPI (Oz Programming Interface), an Emacs-based development environment that provides a REPL, an inspector for live values, and a browser for concurrent thread state. The Inspector is especially valuable for dataflow variable work: it shows the current state of a variable (bound or unbound), the value it is bound to, and the threads currently suspended on it, making thread suspension diagnosis interactive rather than requiring logging instrumentation.

Oz retainer work today covers academic research institutions using Mozart for concurrent programming research, constraint programming applications (scheduling, planning, resource allocation) using Oz’s finite domain (FD) and set constraint solvers, and legacy Mozart applications in industries where Oz was adopted for constraint-intensive logic. Oz expertise is rare; the language is not taught widely outside European computer science programs with roots in the logic programming and constraint programming traditions.

Dataflow variables: the synchronization primitive at the core of Oz concurrency

Oz’s single-assignment dataflow variables are the most distinctive feature of the language. Every fresh occurrence of a capitalized identifier (unless it was previously declared as a variable in the same scope with declare or local) introduces a new unbound dataflow variable. The binding X = 5 is not an assignment in the imperative sense; it is a constraint: X must equal 5. If X is unbound, the constraint binds it to 5. If X is already bound to 5, the constraint is satisfied and execution continues. If X is already bound to something other than 5, the constraint raises an error (a failed computation in the constraint-programming sense).

A thread that tries to read an unbound variable suspends at that read. The suspension is not an error; it is the Oz mechanism for blocking until a value is available, equivalent to blocking on a channel receive in CSP-family languages. The thread is resumed automatically when another thread binds the variable. This means that Oz programs can express producer-consumer patterns without channels or condition variables: the producer thread binds a dataflow variable, and the consumer thread reads it, suspending until the binding happens.

The implicit introduction of fresh variables for any capitalized identifier not in scope is the mechanism that produced the retainer scenario above. In most languages, a misspelled variable name produces a compile-time or runtime undefined-variable error. In Oz, a fresh capitalized identifier is a valid fresh unbound variable. The code thread { process(Va) } end where the intended variable is V is syntactically and semantically valid in Oz: it creates a thread that calls process with a fresh unbound variable Va. The thread suspends inside process at the first read of its argument. The resulting behavior — a suspended thread — looks identical to a correctly written thread that is waiting for its synchronization variable to be bound. Distinguishing the two cases requires checking whether the variable being waited on is the same identifier as the variable being bound in the producer thread.

Thread creation and dataflow synchronization patterns

Oz spawns threads with thread { P } end. Threads share the enclosing variable bindings: a dataflow variable bound in the enclosing scope is visible to the spawned thread. Two threads that reference the same variable name can synchronize on it: if thread 1 binds X and thread 2 reads X, thread 2 suspends until thread 1’s binding fires. The synchronization is implicit in the shared variable reference; no explicit locking or channel operation is required.

The standard dataflow synchronization patterns in Oz are:

Promise pattern: Thread 1 spawns and will eventually bind Result. Thread 2 uses Result and suspends until the binding. The pattern is: local Result in thread { Result = expensiveComputation() } end; downstream(Result) end. downstream suspends until expensiveComputation completes and binds Result.

Stream pattern: Thread 1 produces a stream of values as a list of dataflow variables: Stream = H|T where H is the current head (bound to a value) and T is the next stream variable (unbound, to be bound by the next step). Thread 2 reads the stream, suspending at each unbound tail variable until thread 1 extends the stream. The stream pattern is the dataflow equivalent of a channel: a producer and consumer communicate through a series of dataflow variable bindings rather than through a channel send-receive pair.

Barrier pattern: Multiple threads each bind one element of a tuple: T = f(V1 V2 V3) where thread 1 binds V1, thread 2 binds V2, and thread 3 binds V3. A fourth thread reads the whole tuple and suspends until all three are bound. This implements a join point: the downstream computation waits until all upstream computations complete.

Ports: stateful concurrent communication in Oz

Pure dataflow variables are sufficient for deterministic concurrent programming but not for nondeterministic concurrent communication: a thread cannot safely send a message to a service thread using only dataflow variables, because multiple senders would need to agree on a single binding order. Oz ports solve this by providing a stateful, thread-safe message queue:

{NewPort Stream Port} creates a port Port and a stream Stream. Calling {Send Port Msg} appends Msg to the stream: the next unbound tail of the stream is bound to Msg|NewTail, and a fresh NewTail becomes the new unbound stream end. Multiple threads can safely call Send concurrently: the Mozart runtime handles the atomic extension of the stream. The consumer thread processes the stream sequentially, suspending at each unbound tail and resuming when the next Send binds it.

Port-based communication is the standard Oz pattern for building concurrent servers: the server thread reads a stream of requests sent by multiple client threads via their shared port. The server processes one request per loop iteration, suspending between requests when no new messages have arrived. This is semantically similar to a channel-based server in CSP languages, but with the distinction that the port’s internal queue is a stream of dataflow variables that is shared between sender and receiver, rather than a synchronous rendezvous that blocks the sender.

Concurrent constraint programming in Oz

Oz extends the dataflow variable model with constraint programming: variables can be constrained to domains of values, and propagators narrow those domains as other constraints are added. The finite domain library (FD) supports integer domains: {FD.dom [1 5 10] X} constrains X to the domain {1, 5, 10}. Arithmetic constraints like {FD.plus X Y Z} propagate between domains: if X = 3 and Z = 8, the plus constraint propagates that Y = 5. When propagation reduces a domain to a single value, that variable is effectively bound. When propagation empties a domain, the constraint system has failed (no solution satisfies all constraints).

Constraint programming in Oz is concurrent: propagators run as threads that monitor their constraint variables and fire when their variables’ domains change. A scheduling problem modeled in Oz FD constraints spawns one propagator per constraint; the propagators run concurrently, each narrowing domains as their variables change, until all variables are bound (solution found) or a domain empties (no solution). Search is implemented via spaces: a space is a copy of the current constraint store that can be explored independently, allowing backtracking search to be implemented as a tree of space copies rather than destructive modification of shared state.

Retainer work on Oz constraint programming involves designing the constraint model (which variables, which constraints, what search strategy), debugging propagators that are not firing correctly (a propagator that is supposed to narrow a domain but isn’t may have an incorrect guard condition), and optimizing the search strategy for the specific problem structure (symmetry breaking, value ordering, variable ordering) to reduce search time. This work is intellectually demanding and produces no visible artifact proportional to the hours: a correctly designed constraint model that solves a scheduling problem in 3 seconds versus 3 hours is the result of understanding the search space, which cannot be read from the code.

Typical Oz retainer work and what it looks like in a work log

An Oz retainer typically covers three recurring categories of work. The first is dataflow variable binding diagnosis: tracing thread suspension to identify which variable a thread is waiting on and whether that variable is correctly shared with the binding thread. The Mozart Inspector makes this interactive: selecting a suspended thread shows the variable it is waiting on; selecting that variable shows its current state (unbound) and all threads currently suspended on it. The diagnostic question is: is the binding thread bound to the same identifier? If not, a typo or scope issue introduced a fresh variable. Work log entry: “thread 2 suspended on Va (unbound, no waiting bindings); intended variable V bound by thread 1; Va is fresh variable introduced by typo; corrected to V; V binding in thread 1 correctly resumes thread 2; wrong variable bindings: 1 → 0; 6h.” Without the Oz implicit variable context, the entry reads as six hours to fix a typo.

The second category is port stream protocol design. An Oz port-based server needs a well-defined message protocol: what types of values are sent over the port, how the server distinguishes different message types, how the server signals errors to clients, and how the stream is terminated when the server shuts down. Stream termination is a frequent design issue: the stream tail is an unbound dataflow variable; the server loop must have a termination condition that detects when no more messages will arrive (a sentinel value sent by the last client, a separate control port, or an end-of-stream marker bound as a special value). Work log entry: “designed port protocol for request router: message type {request Req Client} where Client is a fresh port for the response; termination: sentinel stop atom sent by coordinator; error handling: {error Msg} message type in response stream; protocol violations before: 3; after: 0; 8h.”

The third category is constraint model optimization. A constraint model that finds solutions but too slowly typically has one of three issues: the constraint model is missing propagators that would narrow domains early (adding the missing constraints dramatically reduces the search space), the search strategy is using a poor variable-ordering heuristic (switching from first-fail to smallest-domain ordering for this problem structure reduces search by an order of magnitude), or the symmetry in the problem is not being broken (equivalent solutions are being enumerated multiple times; adding symmetry-breaking constraints eliminates the duplicates). Retainer work produces a new constraint model alongside performance measurements showing the improvement. Work log entry: “FD scheduling model: added FD.atMost constraints for resource capacity (3 missing propagators); changed variable ordering from default to smallest-domain; added symmetry breaking for shift equivalences; solution time: 3 hrs → 4 sec on 50-task instance; 9h.”

How HourTab tracks Oz developer retainer hours

Oz retainer work is invisible by the same mechanism that makes Oz’s dataflow model powerful: suspended threads waiting on unbound variables look identical to threads correctly waiting for synchronization to fire. A client who sees “6h — fixed thread synchronization issue” cannot assess whether six hours was proportionate to what sounds like fixing a one-character typo. The work log needs to say: thread 2 called process(Va) and suspended; Va is an unbound dataflow variable with no bindings anywhere in the program; the intended variable V was bound by thread 1’s V = compute(); Va and V are different identifiers, not the same variable in different binding states; typo confirmed by code inspection; corrected from Va to V; thread 2 now suspends on V, which is bound by thread 1 when compute() returns; thread 2 resumes correctly; wrong variable bindings before: 1; after: 0. That log entry is auditable and justifies the hours by showing the implicit fresh variable mechanism, the suspension behavior, and the diagnostic method.

HourTab gives Oz developers a public retainer-hours URL they send to clients — typically academic research groups using Mozart for concurrent programming research, organizations with Oz-based constraint scheduling systems, and developers working with the successor Oz-based systems (Alice ML, Mozart 2). For Oz retainers, each work log entry should name the mechanism at the level of the dataflow model: which variable, which thread was waiting on it, whether the binding thread was using the same identifier, what the suspension cause was, and whether the fix was a binding correction, a scope correction, or a port protocol change. Comparative context for scope discussions: Oz retainer work has conceptual overlap with retainer work on other multi-paradigm languages with concurrent models (Erlang for actor-based concurrency, Scala for futures and promises, Haskell for STM), but the dataflow variable model is unique to Oz and its descendants. Senior Oz expertise commands $150 to $272 per hour because the combination of dataflow model depth, concurrent constraint programming knowledge, Mozart platform expertise, and constraint optimization experience is extremely rare.

FAQ: Oz developer retainers