Argentum threads act as lightweight processes that share the same address space.

Immutable objects are freely shared across all threads while mutable ones belong to exactly one thread. Though threads can pass mutable objects one another.

Threads can acts as workers having no internal mutable state or as microservices with state.

Threads communicate with task queues. So no synchronization primitives needed, no races, no deadlocks.

Moving to multithreaded mode didn't turn reference counters into atomic ones.

Example:

using sys{ Object, Thread, setMainObject, log }

class App {   // Holds mutable state of the main thread.
    // Worker thread, having Object as its internal state.
    worker = Thread(Object).start(Object);
}
app = App;
setMainObject(app);
log("Started on main thread\n");
// Post a new "workerCode" task to the worker Object
// Since it's passed to the object of other thread
// this code will be executed on that thread.
app.worker.root().&workerCode(callback &()) {
    log("Hello from the worker thread\n");
    // Post another task, that we received as a parameter
    callback~();
}~(app.&endEverything() {
    // This "endEverything" task is connected to the
    // main thread object. So it will be activated
    // on the main thread. We pass in to the `callback`
    // parameter.
    log("Shutdown from the main thread\n");

    // `?Object` is a null-pointer of type `Object`.
    // `setMainObject` here deletes previous App instance
    // and as such stops worker thread.
    // And since there is no application state object anymore,
    // application ends.
    setMainObject(?Object);
});

 This code uses one existing and one new operator

Create delegate:

receiver.&delegateName(parameters) { code }

Post delegate to its `receiver` thread queue as an asynchronous task and transfer all parameters to that thread

delegate~(parameters);

More details: https://aglang.org/multithreading/

New Windows demo: https://github.com/karol11/argentum/releases

with `src\threadTest.ag` example.