Mirror of forum.nim-lang.org

258 :: Nimrod and Threading... Again

• NewGuy (orginal) [2013-09-27T10:19:16+02:00] view original

  So I took some time to write out last night's question as clearly as possible. I'm still groggy from a few all nighters (uni's a bitch), but here goes.

  A global GameStateManager contains dynamically created GameStates. Each GameState has two GameStateData objects within (a read_block and write_block).

  The user adds their tasks (function pointers) to the architecture. When completed, the architecture schedules them to each thread - these threads run the tasks on their individual queue (which will be reading from a read_block and writing to a write_block that were (often) created in a different thread - not thread-local copies; a pointer to a dynamic object created).

  How will this behave with Nimrod's GC? Will the reference counting ignore when a reference is made by another thread, Will the cyclic collector work properly, Etc?

  If not, the website says Nimrod is going to have a shared heap for all threads - so when can I expect that kind of functionality?

  Furthermore, when it comes to synchronization, Nimrod uses lightweight mutexes right? The cost of it is akin to critical_sections or C++11 mutexes?

  Thanks in advance everybody.

---

• Araq (orginal) [2013-09-27T21:53:37+02:00] view original

  This sounds exactly like an architecture I would avoid like the plague. Non deterministic, implicit sharing, random control flow, error prone. I can't see it really working out with Nimrod's thread local heaps either.

  There is already a shared heap for you to use, it's just not GC'ed (but then you don't have a GC in C++ either): allocShared etc.

  You can try and make the main thread allocate everything and then worker threads can read this data and even modify it if you really know what you're doing.

  Nimrod's locks are a zero overhead wrapper over mutexes or critial sections.

---

• NewGuy (orginal) [2013-09-27T22:28:17+02:00] view original

  • Purely academic. Never intended to use it beyond saying "look what I did!". Also, this is a pretty widely used design. The engine is based off research from Intel research, a few pretty knowledgable programmers, and the general public's view on how to go about handling it. It's not all that bad as long as you obey a few simple implementation details. Just sayin'.
  • Got it, that's what I thought. The allocate on the main thread idea is a bit more trouble than it's worth. I'm so used to manual memory that it'll just be simpler.
  • Sweet beans.

  Thanks so much, Araq.

---