Guide Concurrency

Concurrency

ARO's concurrency model is radically simple: feature sets are async, statements are sync. This chapter explains how ARO handles concurrent operations without requiring you to think about threads, locks, or async/await.

The Philosophy

ARO's concurrency model matches how project managers think:

• "When X happens, do Y" — Feature sets are triggered by events
• "Do this, then this, then this" — Steps happen in order

You don't think about threads, locks, race conditions, or async/await. You think about things happening and responding to them in sequence.

Feature Sets Are Async

Every feature set runs asynchronously when triggered by an event:

┌─────────────────────────────────────────────────────┐
│                    Event Bus                         │
│                                                      │
│  HTTP Request ──┬──► (listUsers: User API)          │
│                 │                                    │
│  Socket Data ───┼──► (Handle Data: Socket Handler)  │
│                 │                                    │
│  File Changed ──┼──► (Process File: File Handler)   │
│                 │                                    │
│  UserCreated ───┴──► (Send Email: Notification)     │
│                                                      │
│  (Multiple events trigger multiple feature sets     │
│   running concurrently)                              │
└─────────────────────────────────────────────────────┘

When multiple events arrive, multiple feature sets execute simultaneously. 100 HTTP requests = 100 concurrent feature set executions.

Statements Are Sync

Inside a feature set, statements execute synchronously and serially:

(Process Order: Order API) {
    <Extract> the <data> from the <request: body>.      (* 1. First *)
    <Validate> the <data> for the <order-schema>.       (* 2. Second *)
    <Create> the <order> with <data>.                   (* 3. Third *)
    <Store> the <order> in the <order-repository>.      (* 4. Fourth *)
    <Emit> to <Send Confirmation> with <order>.         (* 5. Fifth *)
    <Return> a <Created: status> with <order>.          (* 6. Last *)
}

Each statement completes before the next one starts. No callbacks. No promises. No async/await syntax. Just sequential execution.

Why This Model?

Simplicity

Traditional async code in JavaScript:

async function processOrder(req) {
    const data = await extractData(req);
    const validated = await validate(data);
    const order = await createOrder(validated);
    await storeOrder(order);
    await emitEvent('OrderCreated', order);
    return { status: 201, body: order };
}

ARO code:

(Process Order: Order API) {
    <Extract> the <data> from the <request: body>.
    <Validate> the <data> for the <order-schema>.
    <Create> the <order> with <data>.
    <Store> the <order> in the <order-repository>.
    <Emit> to <Send Confirmation> with <order>.
    <Return> a <Created: status> with <order>.
}

No async. No await. Just statements in order.

No Race Conditions

Within a feature set, there's no shared mutable state problem:

• Variables are scoped to the feature set
• Statements execute serially
• No concurrent access to the same data

Natural Event Flow

Events naturally express concurrency:

• User A requests an order while User B requests their profile
• Both feature sets run concurrently
• Each processes their own data independently

Runtime Optimization

While you write synchronous-looking code, the ARO runtime executes operations asynchronously based on data dependencies. This is transparent to you.

How It Works

The runtime performs data-flow driven execution:

1. Eager Start: I/O operations begin immediately (non-blocking)
2. Dependency Tracking: The runtime tracks which variables each statement needs
3. Lazy Synchronization: Only wait for data when it's actually used
4. Preserved Semantics: Results appear in statement order

Example

(Process Config: File Handler) {
    <Open> the <config-file> from the <path>.        (* 1. Starts file load *)
    <Compute> the <hash> for the <request>.          (* 2. Runs immediately *)
    <Log> <request> to the <console>.                (* 3. Runs immediately *)
    <Parse> the <config> from the <config-file>.     (* 4. Waits for file *)
    <Return> an <OK: status> with <config>.
}

What happens:

• Statement 1 kicks off file loading (async, returns immediately)
• Statements 2 and 3 execute while the file loads in background
• Statement 4 waits only if the file isn't ready yet
• You see: synchronous execution
• Runtime does: parallel I/O with sequential semantics

Write synchronous code. Get async performance.

Event Emission

Feature sets can trigger other feature sets:

(Create User: User API) {
    <Extract> the <data> from the <request: body>.
    <Create> the <user> with <data>.
    <Store> the <user> in the <user-repository>.

    (* Triggers other feature sets asynchronously *)
    <Emit> to <Send Welcome Email> with <user>.

    (* Continues immediately, doesn't wait for handler *)
    <Return> a <Created: status> with <user>.
}

(Send Welcome Email: Notifications) {
    <Extract> the <email> from the <event: email>.
    <Send> the <welcome-email> to the <email>.
    <Return> an <OK: status>.
}

When <Emit> executes:

1. The event is dispatched to the target feature set
2. Execution continues in the current feature set
3. The target handler starts executing independently

No Concurrency Primitives

ARO explicitly does not provide:

• async / await keywords
• Promises / Futures
• Threads / Task spawning
• Locks / Mutexes / Semaphores
• Channels
• Actors
• Parallel for loops

These are implementation concerns. The runtime handles them. You write sequential code that responds to events.

Examples

HTTP Server

(Application-Start: My API) {
    <Start> the <http-server> on port 8080.
    <Keepalive> the <application> for the <events>.
    <Return> an <OK: status>.
}

(* Each request triggers this independently *)
(getUser: User API) {
    <Extract> the <id> from the <pathParameters: id>.
    <Retrieve> the <user> from the <user-repository> where id = <id>.
    <Return> an <OK: status> with <user>.
}

Socket Echo Server

(Application-Start: Echo Server) {
    <Start> the <socket-server> on port 9000.
    <Keepalive> the <application> for the <events>.
    <Return> an <OK: status>.
}

(* Each client message triggers this independently *)
(Handle Data: Socket Event Handler) {
    <Extract> the <data> from the <event: data>.
    <Extract> the <connection> from the <event: connection>.
    <Send> the <data> to the <connection>.
    <Return> an <OK: status>.
}

File Watcher

(Application-Start: File Watcher) {
    <Watch> the <directory> for the <changes> with "./watched".
    <Keepalive> the <application> for the <events>.
    <Return> an <OK: status>.
}

(* Each file change triggers this independently *)
(Handle File Change: File Event Handler) {
    <Extract> the <path> from the <event: path>.
    <Extract> the <type> from the <event: type>.
    <Compute> the <message> from "File " + <path> + " " + <type>.
    <Log> <message> to the <console>.
    <Return> an <OK: status>.
}

Summary

Concept	Behavior
Feature sets	Run async (triggered by events)
Statements	Appear sync (serial execution)
I/O operations	Async under the hood
Events	Non-blocking dispatch
Concurrency primitives	None needed

Write synchronous code. Get async performance. No callbacks, no promises, no await.