Mirror of forum.nim-lang.org

6358 :: How can I pass shared memory between threads?

• Keithcat1 (orginal) [2020-05-20T20:16:28+02:00] view original

  Hi, Does Nim have some good ways to handle shared memory? The only way I found was manual memory management, but that can't handle inner references and, hello, that's the reason I'm using a garbage collected language in the first place :D The experimental manual says that the parallel statement supports shared memory, but I couldn't figure it how. If Nim doesn't have this now, are there future plans that will improve this situation? Will there be a garbage collection algorithm that allocates all ref T on a shared heep, supports passing them between threads, and frees the memory when possible?

---

• mratsim (orginal) [2020-05-20T21:00:29+02:00] view original

  You can implement atomic refcounting with destructors. See what I do in my multithreading runtime:

  type
    FlowEvent* = object
      e: EventPtr
    
    EventPtr = ptr object
      refCount: Atomic[int32]
      kind: EventKind
      union: EventUnion
  
  # Refcounting is started from 0 and we avoid fetchSub with release semantics
  # in the common case of only one reference being live.
  
  proc `=destroy`*(event: var FlowEvent) =
    if event.e.isNil:
      return
    
    let count = event.e.refCount.load(moRelaxed)
    fence(moAcquire)
    if count == 0:
      # We have the last reference
      if not event.e.isNil:
        if event.e.kind == Iteration:
          wv_free(event.e.union.iter.singles)
        # Return memory to the memory pool
        recycle(event.e)
    else:
      discard fetchSub(event.e.refCount, 1, moRelease)
    event.e = nil
  
  proc `=sink`*(dst: var FlowEvent, src: FlowEvent) {.inline.} =
    # Don't pay for atomic refcounting when compiler can prove there is no ref change
    `=destroy`(dst)
    system.`=sink`(dst.e, src.e)
  
  proc `=`*(dst: var FlowEvent, src: FlowEvent) {.inline.} =
    `=destroy`(dst)
    discard fetchAdd(src.e.refCount, 1, moRelaxed)
    dst.e = src.e
  Run

  Multithreaded garbage collection is a very hard problem and it took years for Java to nail it.

  The parallel statement has a proof-of-concept array bound checking algorithm that can prove at compile-time that arrays/seq accesses are safe to be made concurrently because the cells are not updated by different threads. It's mostly a proof-of-concept though and the future Z3 integration (a SMT solver) is in part motivated to extend this capability as far as I know.

  If you compile with --gc:boehm or --gc:arc memory is allocated on a shared heap. Though I'm currently having trouble with --gc:arc + --threads:on its main motivation is easing multithreading.

  Note that for data structures shared between threads you will still need to handle them via destructors + atomic refcounting, there is no plan to add atomic overhead to all types managed by the GC.

  Furthermore Nim encourages using message-passing (i.e. share-memory by communicating instead of communicating by sharing).

---