Mirror of forum.nim-lang.org

9099 :: Shared memory with ARC

• DeletedUser (orginal) [2022-04-10T19:28:37+02:00] view original

  How can I define a shared, gcsafe mutable variable to use between threads with --gc:arc? I'm thinking about a construct like Rust's Arc<_> and using it with threadpool.

---

• planetis (orginal) [2022-04-10T20:12:15+02:00] view original

  The equivalent is SharedPtr from threading/smartptrs

---

• mratsim (orginal) [2022-04-11T00:45:56+02:00] view original

  Arc in Rust stands for Atomic Reference Counting.

  Arc in Nim stands for Automatic Reference Counting.

  For a shared mutable variable you need to consider ownership:

  • which thread allocates the variable, which thread deallocates. For example if there is a master thread that create and destroy child threads, you can ensure that data lives long enough by having alloc/dealloc in the master thread. On the other hand, if data can be allocated and deallocated from any thread, you need atomic reference counting, which can be implemented in a couple dozens lines: https://github.com/mratsim/weave/blob/71dc2d7/weave/cross_thread_com/flow_events.nim#L176-L201=
  • can mutation be concurrent on the same data (and so need synchronization) or not (say parallel map on a sequence/vector)

---

• elcritch (orginal) [2022-04-11T02:16:21+02:00] view original

  I'd second threading/smartptrs if you need shared mutable data. SharedPtr uses an atomic reference count which is equivalent with Rust's Arc<T> type. Though SharedPtr like Rust's Arc<T> doesn't provide for locking the data. Though you should be able to pass SharedPtr via a channel. It should just increment the ref count.

  Note too that SharedPtr requires your data to be isolate compatible. If the compiler can't verify the data is isolated you may need to copy the data once on initialization. You can use unsafeIsolate if you have a big blog of data that can't be copied and which doesn't make isolate() happy.

  @mratsim's work pools are much nicer if you can refactor the problem into a map-reduce style parallelism.

---