On 14.10.2013 21:42, Michel Fortin wrote:
Indeed. The current garbage collector makes it easy to have shared
pointers to shared objects. But the GC can also interrupt real-time
threads for an unpredictable duration, how do you cope with that in a
real-time thread?
The work I was talking about uses C++, not D, so there is no GC involved.
The options I see for real-time threads in D is either a concurrent GC
(which means read/write barriers for pointer accesses) or just excluding
the real time thread from suspension by the GC. This forces the
programmer to ensure that references in the real time thread are also
found elsewhere. I'm not sure if this eliminates the benefits regarding
locking, though.
I know ARC isn't the ideal solution for all use cases. But neither is
the GC, especially for real-time applications. So, which one would you
recommend for a project having a real-time audio thread?
ARC doesn't work for real time threads anyway, because you are not
allowed to deallocate if it can cause locks. It can only work if you
defer reference counting into another thread through some buffering.
Realistically I would currently recommend the approach above: exclude
the thread from suspension, and keep a reference to used object
elsewhere. This is probably about as difficult as avoiding
allocations/deallocations in C++, but harder to debug.
