Mirror of forum.nim-lang.org

9378 :: Explain current state of multi-threading

• gavr (orginal) [2022-08-17T13:34:24+02:00] view original

  Explain the situation with multi-threading, now it seems to me a little confusing. With GC: refc heaps are local for each thread. Therefore, it is only possible to copy shared data, or manual control via ptr (which is unsafe). With GC: ARC/ORC heap is shared so data can be moved. ARC doesnt use atomic counters so you need to manually lock data(which is eventually unsafe). Another option is to use channels with data copying as in refc.

  Channels have a number of disadvantages: "Note: This is part of the system module. Do not import it directly. To activate thread support compile with the --threads:on command line switch. Note: Channels are designed for the Thread type. They are unstable when used with spawn Note: The current implementation of message passing does not work with cyclic data structures. Note: Channels cannot be passed between threads. Use globals or pass them by ptr."

  There are also isolates(https://github.com/nim-lang/RFCs/issues/244), which are an evolution of the idea of owned ref. I'm not sure I understand correctly what is meant by "pass subgraphs to threads", what is subgraph? But in general, this is an opportunity to put data in a container that will check that a number of restrictions for that data are not violated, which guarantees the safe movement of data into channels (instead of copying). And most importantly, they are not ready either.

  So the question is, what ways to work with shared data are relevant for ARC/ORC right now?

---

• jasonfi (orginal) [2022-08-17T17:02:37+02:00] view original

  I've heard that it's advised to use the new channels with ARC/ORC: https://github.com/nim-lang/threading.

  This should be at the top of the stdlib channels docs, in my opinion.

---

• mratsim (orginal) [2022-08-18T15:53:08+02:00] view original

  There are multiple topics to cover:

  1. Sharable memory between threads
  2. Safely reclaiming that memory
  3. Synchronizing primitives

  Sharable memory between threads.

  To create memory that can be shared, you need to ensure that the memory backing the data processed in another thread is valid through that processing.

  You can ensure that with:

  • Allocation, anywhere, stack, local heap or shared heap (any GC) if your data is plain old data (no ref/seq/strings) AND the parallel processing is guaranteed to finish before the function ends (via blocking). This is called structured parallelism, async/concurrency has reached a similar conclusion more recently (https://en.wikipedia.org/wiki/Structured_concurrency)
  • Allocation of plain old data, manually (no ref/seq/strings) via allocShared or allocShared0 (any GC). Deallocation is done manually as well, this is basically C mode.
  • If using seq/strings that are shared between threads, you can get away with using any GC, if you only mutate existing data, but not the metadata, i.e. you need to deal with creation and append in a single thread, but mutating existing data from any thread is fine, providing proper synchronization.
  • The most flexible for shared ref/seq/strings is using a GC with a global heap instead of thread-local heaps: --arc, --orc, --boehm. But similar to 1, while many can access it, one thread is the owner, initially the creator. The owner is the data allocator and responsible for future deallocation, but for ref/seqs/strings the owner can change (using channels).

  Safely reclaiming memory

  1. If you use structured parallelism with plain old data and only do multithreading within a function that blocks until parallel processing is finished, all memory reclamation is automatic.
  2. If you use manual memory management, make sure that memory is deallocated at the end, and also that deallocation only occurs at the end. You can use Nim's atomic refcount at https://github.com/nim-lang/threading/blob/49562fa/threading/smartptrs.nim#L77-L132 if needed.
  3. Similar to 1
  4. Similar to 1

  Synchronization

  You can get away with no synchronization primitive if your algorithm is guaranteed to never touch the same memory at the same time, typically this is a parallel for. This is called Data Parallelism.

  When memory might cause conflict, you can use a lock to ensure consistent ordering of operations and avoid corruption.

  Lastly, you can also ensure that any one point in time, only one thread has visibility on an object, its owner, and ownership is passed from "service" to "service" each running on their threads, basically a thread-level microservice architecture or producer-consumer architecture that communicate via channels.

---