Origin’sDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/boblio-max/origin/llms.txt
Use this file to discover all available pages before exploring further.
parallel block lets you express concurrent computation without writing a single line of thread management code. Wrap a group of statements in parallel { } and Origin’s interpreter generates per-statement threads automatically — each statement becomes its own threading.Thread, all threads are started together, and execution resumes only after every thread has finished.
Syntax
parallel { } block runs in its own thread. All threads are started before any of them are joined, so independent work overlaps. Execution of the code that follows the block does not begin until every thread inside the block has completed.
Optional Thread Count
You can pass an explicit thread count withparallel(N):
N identical threads — each thread calls the same block body. When no count is given (the common case), each top-level statement in the block gets its own thread.
How It Works: Code Generation
When the Origin interpreter encounters aParallelNode, it generates Python threading code directly during the transpilation step. No external engine is invoked at this stage — the threading setup is emitted as ordinary Python source.
For a parallel { } block with no explicit count, the interpreter generates one named function and one thread per statement, then joins all threads:
parallel(N) block, a single _parallel_block() function is defined and started N times:
for t in _threads: t.join() line at the end is the thread barrier — it ensures the parallel block is fully complete before any following statement runs.
Complete Example
read_sensor calls run in parallel threads. After the barrier, total is computed using all four results.
The parallelInt Engine
Origin ships a second, more advanced execution engine called parallelInt that performs wavefront dependency analysis on the full program AST before running anything. This engine is separate from the standard origin run pipeline — it is an alternative runner used for research and experimentation.
The parallelInt engine analyses every statement in the whole program (not just a parallel block) and automatically groups them into numbered stages:
| Hazard | Condition |
|---|---|
| RAW (read-after-write) | an earlier statement writes a variable that a later one reads |
| WAW (write-after-write) | two statements write the same variable |
| WAR (write-after-read) | an earlier statement reads a variable that a later one writes |
| SFIO (side-effect ordering) | both statements carry observable side effects |
parallelInt API call signature is:
ProgramNode AST returned by parser.Parser, not a sub-tree. Both shared_globals and verbose are optional.
Thread Safety and Shared State
All threads within aparallel block share the same Python dict of globals, passed directly to Python’s exec(). This means:
- Variables written inside the block are visible to statements that follow the block, because the join barrier guarantees all threads have finished before execution continues.
- Two statements in the same
parallel { }block should write to different variables. If two threads write the same variable concurrently, the result is a data race. - Statements with side effects —
print,input, GPIOset,import, and nestedexec— run in separate threads and their order relative to each other is not guaranteed.
The
parallel {} block in the standard interpreter generates one thread per top-level statement. For automatic dependency-aware scheduling across an entire program, see the parallelInt engine described above, which is a separate execution path from the normal origin run command.