2026-04-01·9 min read·sota.io team

Deploy Occam to Europe — CSP Concurrency on EU Infrastructure in 2026

Most concurrent programming models share state and synchronise access with locks. Occam does not.

In Occam, concurrent processes communicate exclusively through channels — typed, point-to-point conduits that carry a single value from one process to another. A channel has exactly one sender and exactly one receiver. When the sender writes, it blocks until the receiver reads; when the receiver reads, it blocks until the sender writes. This rendezvous synchronisation means that communication events are instantaneous, atomic, and observable — there is no buffering, no race condition, and no moment when data exists in a state that two processes can simultaneously access.

This design was not an implementation convenience. It was a direct realisation in hardware and software of Tony Hoare's theory of Communicating Sequential Processes (CSP), published at Oxford in 1978. CSP gave concurrent programming its first rigorous mathematical foundation — a process algebra in which concurrent systems could be modelled, reasoned about, and formally verified before a single line of code was compiled. Occam was the language that turned this theory into executable programs, and the Transputer was the processor that turned those programs into parallel silicon.

Both were built in Bristol.

Tony Hoare and CSP: Oxford's Formal Theory of Concurrency

Sir Charles Antony Richard Hoare 🇬🇧 KBE FRS FREng — Tony Hoare — is one of the most decorated computer scientists in European history. His contributions span four decades: Quicksort (1959/1960, Elliott Brothers Ltd), Hoare logic (axiomatic semantics for program correctness, 1969), and CSP (1978). He was awarded the ACM Turing Award in 1980. He was appointed Knight Commander of the Order of the British Empire in 2000. He has been a Fellow of the Royal Society since 1982.

Hoare developed CSP during his tenure as Professor of Computation at Oxford University (1977–1999). The core insight of CSP is that a concurrent system can be modelled as a composition of sequential processes that communicate only through synchronised message passing. A process in CSP is defined by the events it can engage in and the order in which it engages in them. Two processes run in parallel. When they share a channel event, they synchronise; otherwise they proceed independently. The composition of two CSP processes produces a new process whose behaviour is precisely specified by the behaviours of its components.

This compositional specification model makes formal verification tractable. Given a CSP description of a concurrent system, tools like FDR (Failures-Divergences Refinement, developed by Bill Roscoe 🇬🇧 at Oxford) can check whether the system satisfies safety and liveness properties — whether a deadlock is possible, whether a required event always eventually occurs, whether a security property is never violated. The verification is mathematical, not statistical. It checks all possible execution paths.

-- Occam: CSP channels as first-class language primitives
-- Tony Hoare 🇬🇧 (Oxford) + David May 🇬🇧 (Inmos, Bristol)

CHAN OF INT pipeline:
CHAN OF INT result:

PAR
  -- Producer process: generates integers on pipeline channel
  SEQ i = 0 FOR 100
    pipeline ! i            -- send: blocks until consumer reads

  -- Filter process: passes only even numbers
  SEQ
    WHILE TRUE
      INT n:
      SEQ
        pipeline ? n         -- receive: blocks until producer sends
        IF
          (n \ 2) = 0       -- rendezvous: atomic, observable
            result ! n
          TRUE
            SKIP

  -- Consumer process: collects results
  SEQ
    WHILE TRUE
      INT n:
      SEQ
        result ? n
        -- process even integer n

Occam's syntax makes the CSP structure explicit: PAR introduces parallel composition; SEQ introduces sequential composition; ! sends on a channel; ? receives. There is no keyword for "lock", "mutex", or "semaphore" because there is no shared mutable state to protect. The channel is the only mechanism of interaction between parallel processes.

David May and the Transputer: Concurrent Hardware from Bristol

David May 🇬🇧 FRS FREng is Professor of Computer Science at the University of Bristol and the architect of two of the most influential parallel computing systems in European history. At Inmos Ltd in Bristol in 1983, he designed both the Occam programming language and the Transputer microprocessor. They were designed together, as a unified system: a processor whose instruction set was the direct hardware implementation of Occam's process model, and a language whose semantics were the direct software expression of the processor's channel architecture.

Inmos Ltd was founded in 1978 in Bristol with funding from the UK's National Enterprise Board — a British government initiative to build a semiconductor industry capable of competing with US and Japanese manufacturers. The company's founders included Richard Petritz and Paul Schroeder, but its intellectual engine was its Bristol engineering team, which produced the T212, T414, and T800 Transputer series. The T800 (1985) combined a 32-bit RISC core, a floating-point unit, and four serial communication links — the hardware implementation of Occam channels — in a single package. Transputers could be tiled into arbitrarily large parallel arrays by connecting their serial links: four links out of each processor, each carrying an Occam channel.

-- Transputer farm: process network on Occam/Transputer hardware
-- Inmos T800 (1985), Bristol, UK
-- Each PLACED PAR branch ran on a separate physical Transputer chip

PLACED PAR
  PROCESSOR 0               -- Transputer 0: input coordinator
    coordinator(input, link0, link1, link2, link3)

  PROCESSOR 1               -- Transputer 1: worker process
    worker(link0.to.1, result0)

  PROCESSOR 2               -- Transputer 2: worker process
    worker(link1.to.2, result1)

  PROCESSOR 3               -- Transputer 3: worker process
    worker(link2.to.3, result2)

  PROCESSOR 4               -- Transputer 4: output collector
    collector(result0, result1, result2, output)

-- Each link is a hardware Occam channel: 10 Mbit/s point-to-point
-- No bus arbitration, no shared memory, no coherence protocol
-- Pure CSP: all communication is rendezvous on typed channels

The Transputer was used in the Edinburgh Concurrent Supercomputer (ECS), in Meiko Computing Surfaces deployed at UK and European universities, and in Parsytec 🇩🇪 systems (Parsytec GmbH, Aachen, Germany — one of the largest European Transputer manufacturers). The Parsytec GCel and GC/PowerPlus systems were deployed at CERN 🇨🇭 in Geneva and at German university computing centres. The Transputer was a European answer to the American Connection Machine and was for a decade the dominant platform for EU parallel computing research.

STMicroelectronics: The French Heir to Inmos

Inmos Ltd was acquired by Thorn EMI in 1984, then sold to SGS-Thomson Microelectronics in 1989. SGS-Thomson became STMicroelectronics in 1998. Today, STMicroelectronics 🇫🇷🇮🇹 is headquartered in Geneva 🇨🇭, with its primary European engineering centres in Grenoble 🇫🇷 (France), Agrate Brianza 🇮🇹 (Italy), and Crolles 🇫🇷 (France). It is one of the world's largest semiconductor manufacturers and a European industrial champion in the EU Chips Act framework.

STMicroelectronics is the institutional heir to the Inmos Transputer IP, and it carries forward the CSP architectural insight in its embedded microcontroller lines. The STM32 family — manufactured in Crolles, France and used in hundreds of millions of EU industrial devices — inherits design lineage from the Inmos engineering culture. The company is a named beneficiary of EU Chips Act funding (Regulation (EU) 2023/1781) for expanding European semiconductor manufacturing capacity.

The fact that Occam, designed in Bristol on UK government funding, ended up as part of a French-Italian-Swiss publicly-listed European semiconductor company is not a commercial curiosity. It is a map of how European industrial policy built the computing substrate on which EU critical infrastructure now runs.

XMOS: CSP Channels in Modern Silicon

In 2005, David May and a team of engineers from the original Inmos Bristol group founded XMOS Ltd 🇬🇧 in Bristol. XMOS makes the xCore processor — a multi-threaded chip with eight hardware threads per tile, dedicated inter-tile channel links, and a deterministic execution model. The programming model for xCore is XC — a C extension with Occam-style channel communication as a first-class language feature.

XMOS processors are deployed in professional audio equipment (JBL, Sonos), industrial robotics, high-speed motor control, and IoT sensing systems. Every XMOS chip processes concurrent real-time data streams via typed, synchronised channels — the same model Tony Hoare described at Oxford in 1978 and David May implemented in Bristol in 1983. The heritage is direct: same city, same engineer, same mathematical foundation.

/* XMOS XC: Occam-style CSP channels in modern embedded C */
/* David May 🇬🇧 (XMOS, Bristol, 2005) — xCore architecture */

#include <xs1.h>
#include <print.h>

/* Channel interface: typed, synchronised, point-to-point */
interface AudioProcessor {
  void process_frame(int32_t samples[], unsigned count);
  int32_t get_peak_level(void);
};

/* Server process: handles audio frames on dedicated hardware thread */
void audio_server(server interface AudioProcessor ap) {
  int32_t peak = 0;
  while (1) {
    select {
      case ap.process_frame(int32_t s[], unsigned n):
        /* Rendezvous: caller blocks until this case executes */
        for (unsigned i = 0; i < n; i++) {
          if (abs(s[i]) > peak) peak = abs(s[i]);
        }
        break;
      case ap.get_peak_level() -> int32_t level:
        level = peak;
        peak = 0;         /* reset after reading */
        break;
    }
  }
}

/* Client process: runs on separate hardware thread, no shared state */
void audio_client(client interface AudioProcessor ap) {
  int32_t frame[256];
  /* fill frame with samples ... */
  ap.process_frame(frame, 256);   /* rendezvous with server */
  int32_t level = ap.get_peak_level();
  printint(level);
}

/* par: two hardware threads, zero shared mutable state */
int main() {
  interface AudioProcessor ap;
  par {
    audio_server(ap);
    audio_client(ap);
  }
  return 0;
}

The XMOS xCore processor executes this code with deterministic timing — each instruction takes a known number of nanoseconds, and channel communication takes a known number of cycles. This determinism is a formal guarantee, not a probabilistic estimate. It is the property that makes XMOS processors suitable for audio processing (where jitter is audible), motor control (where timing errors cause physical damage), and safety-critical systems (where non-determinism is a certification blocker).

Deploying Occam via KRoC on sota.io

KRoC (Kent Retargetable occam Compiler) is the primary modern Occam implementation, developed by Peter Welch 🇬🇧 and Fred Barnes 🇬🇧 at the University of Kent in Canterbury. KRoC compiles Occam-π (Occam extended with Robin Milner's π-calculus process mobility features) to native code via POSIX threads, implementing Occam channels as OS-level synchronised structures. KRoC runs on Linux and produces standard ELF binaries.

Step 1 — Write an Occam HTTP service:

-- http-server.occ — Occam-π HTTP service via KRoC
-- KRoC: Peter Welch 🇬🇧 + Fred Barnes 🇬🇧 (University of Kent, Canterbury)

#INCLUDE "sock.module"    -- KRoC socket library
#INCLUDE "string.module"  -- KRoC string operations

-- Request handler process: one per connection, fully isolated
PROC handle.connection(SOCKET conn)
  [512]BYTE request:
  INT bytes.read:
  SEQ
    sock.read(conn, request, bytes.read)  -- read HTTP request
    -- Parse path from request
    [256]BYTE response:
    INT resp.len:
    SEQ
      string.make(response, resp.len,
        "HTTP/1.1 200 OK*c*n")
      string.append(response, resp.len,
        "Content-Type: application/json*c*n")
      string.append(response, resp.len,
        "Content-Length: 42*c*n*c*n")
      string.append(response, resp.len,
        "{""status"":""ok"",""runtime"":""occam"",""region"":""eu""}")
      sock.write(conn, response, resp.len)
      sock.close(conn)

-- Listener process: accepts connections, spawns handler per connection
PROC http.listener(VAL INT port)
  SOCKET server.sock:
  SEQ
    sock.listen(server.sock, port)
    WHILE TRUE
      SOCKET client.sock:
      SEQ
        sock.accept(server.sock, client.sock)
        -- FORK: spawn isolated handler process (Occam-π mobile process)
        FORK handle.connection(client.sock)

PROC main()
  SEQ
    http.listener(8080)

Step 2 — Compile with KRoC:

# Install KRoC on Debian
apt-get install -y kroc

# Compile Occam-π source to native binary
kroc -o http-server http-server.occ

# Run: accepts HTTP connections via POSIX thread pool
./http-server
# → Listening on :8080
# → Each connection: isolated FORK process, no shared state
# → Channel communication: zero-copy rendezvous

Step 3 — Containerise for sota.io:

FROM debian:bookworm-slim AS builder

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       kroc \
       build-essential \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /build
COPY http-server.occ .
RUN kroc -o http-server http-server.occ

FROM debian:bookworm-slim
WORKDIR /app
COPY --from=builder /build/http-server .

# KRoC runtime libraries
COPY --from=builder /usr/lib/kroc/ /usr/lib/kroc/
COPY --from=builder /usr/lib/libkrocif.so* /usr/lib/

EXPOSE 8080
CMD ["./http-server"]

Step 4 — Deploy to EU infrastructure:

# Deploy Occam backend to Germany via sota.io
sota login
sota init --name occam-backend --region eu-central-1
sota deploy

# Output:
# ✓ Build completed (KRoC → native ELF on Debian bookworm-slim)
# ✓ Deployed to fra1.sota.io (Frankfurt, Germany)
# ✓ GDPR: data residency EU enforced
# ✓ No CLOUD Act exposure (no US parent entity)
# ✓ URL: https://occam-backend.sota.io

The GDPR's Article 5(1)(f) requires that personal data be processed with appropriate security, including protection against accidental or unlawful alteration — the integrity and confidentiality principle. In most concurrent systems, this principle requires explicit enforcement: access locks, atomic operations, memory barriers. Race conditions are not theoretical — they are a class of production bug that can corrupt database records, expose user data to the wrong session, or allow two processes to simultaneously write inconsistent values to shared state.

In Occam, this class of bug cannot occur. There is no shared mutable state to race on. Every piece of data belongs to exactly one process at any moment, and moves between processes exclusively through typed channel rendezvous events. The rendezvous is atomic by construction — the sender does not proceed until the receiver has taken the value; the receiver does not proceed until the sender has provided it. Between the offer and the acceptance, there is no intermediate state.

-- GDPR Art. 5(1)(f) integrity: no shared state, no race conditions
-- User record ownership: exactly one process holds a record at any time

CHAN OF UserRecord request.chan:
CHAN OF UserRecord response.chan:

-- Database process: SOLE owner of user records
-- No other process can read or write user data directly
PROC user.database(CHAN OF QueryRequest req, CHAN OF UserRecord resp)
  [MAX.USERS]UserRecord users:
  WHILE TRUE
    QueryRequest q:
    SEQ
      req ? q                    -- receive query: blocks until request arrives
      UserRecord r:
      SEQ
        -- Look up user — this process is the only reader/writer
        find.user(users, q.user.id, r)
        -- GDPR Art. 5(1)(f): record is in exactly one process at any time
        resp ! r                 -- send record: blocks until receiver reads

-- API process: requests records, receives them — never holds them simultaneously
-- with the database process (channel rendezvous enforces mutual exclusion)
PROC api.handler(CHAN OF QueryRequest out.req, CHAN OF UserRecord in.resp)
  WHILE TRUE
    QueryRequest req:
    SEQ
      -- receive HTTP request, build query...
      out.req ! req              -- send: blocks until database receives
      UserRecord user:
      SEQ
        in.resp ? user           -- receive: blocks until database sends
        -- process user record, send HTTP response
        -- user is ONLY in this process now — database has given it up

This structural guarantee — data ownership by channel transfer, not shared access — means that GDPR Article 5(1)(f) integrity is enforced by the language's type system and execution model, not by programmer discipline. There is no code pattern that violates it. There is no lock to forget to acquire. The data model is correct by construction.

CSP Model Checking and EU AI Act Article 9

The EU AI Act's Article 9 requires high-risk AI systems to implement risk management measures including analysis and testing of known risks. For systems with concurrent execution paths, this includes verifying that concurrent processes cannot deadlock, that safety-critical events always eventually occur, and that no execution path can lead to a hazardous state.

CSP's formal process algebra makes this verification tractable. The FDR4 (Failures-Divergences Refinement) tool, developed by Bill Roscoe 🇬🇧 and the Oxford Concurrency Group at the University of Oxford, accepts CSP process descriptions and checks them against formal specifications. FDR exhaustively explores the reachable state space of a concurrent system and proves or disproves properties about it.

-- CSP specification of a GDPR consent management system
-- Verified with FDR4 (Failures-Divergences Refinement)
-- Bill Roscoe 🇬🇧 (University of Oxford) — CSP model checker

-- Process: ConsentManager
-- Events: request_consent, grant_consent, deny_consent, process_data, delete_data
ConsentManager =
  request_consent ->
    (grant_consent -> process_data -> delete_data -> ConsentManager
    []
    deny_consent -> ConsentManager)

-- Property: data is never processed without consent having been granted
-- Expressed as a CSP refinement check
-- FDR4 proves: ConsentManager [T= NoUnconsentedProcessing
-- ✓ PASS: no execution path processes data without prior consent grant

-- EU AI Act Art. 9 high-risk AI: FDR4 proves safety property
-- over ALL possible execution orderings, not just tested paths
-- Mathematical proof, not probabilistic test coverage

This verification is not testing. It is mathematical proof over all possible execution paths of the concurrent system. For a high-risk AI system under EU AI Act Article 9, FDR4 verification of a CSP model produces evidence of due diligence that no amount of statistical test coverage can replicate.

The CSP Legacy in Modern Languages

Occam and CSP did not remain confined to academic research and Transputer hardware. Their channel-based concurrency model propagated into the mainstream of software engineering:

CSP (1978)          Tony Hoare 🇬🇧 (Oxford)
    │
    ├── Occam (1983)         David May 🇬🇧 (Inmos, Bristol)
    │       ├── Occam-π      Peter Welch 🇬🇧 (University of Kent, Canterbury)
    │       │                π-calculus: Robin Milner 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇬🇧 (Cambridge, Turing Award 2008)
    │       └── XC (XMOS)    David May 🇬🇧 (XMOS Ltd, Bristol, 2005)
    │
    ├── Go channels (2009)   Pike + Thompson (Google) — explicit CSP attribution
    │       └── goroutines   "Don't communicate by sharing memory;
    │                         share memory by communicating" — CSP maxim
    │
    ├── Erlang actors (1986) Joe Armstrong 🇸🇪 (Ericsson, Stockholm)
    │       └── OTP          Process isolation + message passing = CSP without types
    │
    ├── Rust channels (2015) Mozilla — std::sync::mpsc = multi-producer, single-consumer
    │       └── async/await  Tokio channels = typed rendezvous in async context
    │
    └── π-calculus (1992)    Robin Milner 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇬🇧 (Cambridge) — process mobility
            └── Session Types Vasconcelos 🇵🇹 + Gay 🇬🇧 — typed channels in type theory

Robin Milner 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇬🇧 at the University of Cambridge — Turing Award 2008 — developed the π-calculus (1992) as an extension of CSP with mobile processes and dynamic channel creation. The π-calculus is the theoretical foundation of modern session types, which provide static type-system guarantees for communication protocol correctness. Session types research is active today at Edinburgh, Cambridge, Lisbon 🇵🇹, and Bologna 🇮🇹 — a direct European academic lineage from Hoare's CSP through Milner's π-calculus.

Go's documentation explicitly attributes goroutines and channels to CSP. The Go specification cites Hoare's 1978 paper. When a developer writes go func() and passes a channel, they are writing a Go approximation of an Occam PAR and CHAN. The mental model is the same: parallel processes communicating by synchronised message passing, with no shared mutable state.

Why sota.io for Occam on EU Infrastructure

Occam's history is rooted in British and European computing. Tony Hoare formalised CSP at Oxford. David May implemented it in Bristol. Parsytec deployed Transputer arrays at CERN and German universities. STMicroelectronics — the French-Italian industrial champion — carries the Transputer lineage forward. XMOS continues it in Bristol today.

The concurrency model Hoare designed in 1978 has proven more durable than almost any other abstraction in computing: it underlies Go, Rust channels, Erlang actors, and XMOS silicon. The formal verification tools it enables — FDR4 at Oxford — produce evidence of concurrent system correctness that directly addresses EU AI Act Article 9 requirements. The no-shared-state execution model addresses GDPR Article 5(1)(f) integrity by construction.

sota.io provides EU-native infrastructure for this heritage. German Hetzner hardware, GDPR-compliant data residency, no US CLOUD Act exposure, managed PostgreSQL with automatic DATABASE_URL injection, zero DevOps overhead. Push a KRoC-built Dockerfile, get a Frankfurt URL, scale automatically.

# Occam on sota.io: CSP concurrency on EU infrastructure
sota login
sota init --name occam-service --region eu-central-1
sota deploy

# Output:
# ✓ Build: KRoC → native ELF (Debian bookworm-slim)
# ✓ Region: Frankfurt, Germany (eu-central-1)
# ✓ GDPR: EU data residency enforced
# ✓ EU AI Act Art. 9: FDR4 CSP model checking available
# ✓ No shared state: GDPR Art. 5(1)(f) integrity by construction
# ✓ Heritage: Hoare 🇬🇧 (Oxford) + May 🇬🇧 (Bristol) + ST 🇫🇷 (Grenoble)
# ✓ URL: https://occam-service.sota.io

David May built Occam and the Transputer in Bristol because the UK government decided Europe needed its own parallel computing architecture. Tony Hoare gave him the mathematics at Oxford. STMicroelectronics in Grenoble carried the result forward into the EU semiconductor ecosystem. XMOS in Bristol continues the work today. sota.io runs their heritage where it belongs: on EU soil, under EU law, with the formal verification guarantees and structural data integrity that GDPR, EU AI Act, and NIS2 demand.

Deploy your Occam application to Europe today at sota.io. EU-native infrastructure, GDPR-compliant by default, managed PostgreSQL, zero DevOps overhead.

See also: Deploy Esterel to Europe — synchronous reactive programming (Gérard Berry 🇫🇷 INRIA), Airbus A320 fly-by-wire, formally verified C output · Deploy Lustre to Europe — synchronous dataflow language (Halbwachs 🇫🇷 IMAG Grenoble/VERIMAG), TGV EN 50128, EDF nuclear IEC 61511, French Synchronous School · Deploy Erlang to Europe — concurrent fault-tolerant OTP backends (Ericsson 🇸🇪), actor model, nine nines reliability · Deploy Concurrent Haskell to Europe — Simon Peyton Jones (Glasgow), STM 2001; composable concurrency via Software Transactional Memory, shares CSP's channel-based concurrency philosophy · All languages on sota.io