4 ms·

Depends on your requirements. A hard real-time system discourages any form of dynamic memory management, let alone GC. There are soft real-time GC implementatio

Depends on your requirements. A hard real-time system discourages any form of dynamic memory management, let alone GC. There are soft real-time GC implementations, but they are fairly special beasts. I wouldn't consider any non-soft-real-time GC implementation "badly designed". I get the point about reference counting, but I should point out it depends on the data structure you are dealing with. If you've got a tree-like or list-like data structure with reference counted pointers everywhere, then yes that can cause nondeterministic delays. But if you're reference counting a flat structure containing no reference-counted pointers, or contains some reference counted pointers, but doesn't allow for arbitrarily deep data structures, reference counting delays are completely deterministic. In many cases that can be faster than GC, and definitely uses less memory. Point still stands about the safety issue, there are quite a few CVEs having to do with not properly decrementing the reference count, though C++ shared_pointer and Rusts Rc<> make that safer.

fiddlerwoaroof 10y ago
Even in the flat structure case, doesn't reference counting turn referencing an object into a synchronization point? For example if I try to use several threads to make a million objects reference a single object, I'll have to lock every time I add a reference, reducing parallelism.
- openasocket 10y ago
  Well yes and no. In the multi-threaded case you'd use ARC (atomic reference count) pointers. These use atomic instructions to increment and decrement references, and are thus lock-free. There's still contention, but only on the data bus and the cache coherency protocol for the atomic instructions. Under contention, you're looking at latency for access less than 80-100ns. Of course, if all of these threads are accessing an object at once you're going to have contentions no matter what, unless all of the threads are read-only.
- kazinator 10y ago
  Reference counting is a form of GC. It has nondeterministic delays. You don't know which dropref() operation will just decrement and which will finalize. Moreover, when refcounted objects finalize, they recursively drop the refs they hold. Of course, in some trivial cases it is obvious. But in those cases, you could use manual memory management. For instance, trivial case: making an object and then dropping it in the same scope.
  - dllthomas 10y ago
    > Moreover, when refcounted objects finalize, they recursively drop the refs they hold. You can (at the cost of some additional complication) make this more deterministic by adding newly-dead objects to a "finalize this soon" queue and chewing through that when you have time (or on a different thread).
adrianN 10y ago
Do hard real time systems discourage dynamic memory because historically there were no systems that could provide real time guarantees or because of some theoretical barriers? I think it's the former.
- openasocket 10y ago
  There's other issues. Like the fact that you could run out of memory and allocation fails. Then what do you do? For hard real time systems crashing isn't acceptable, so you have to continue on, but assuming you actually needed that data you tried to allocate that's not going to be easy. So you need to prove your system won't ever allocate too much memory. That's pretty hard to do, and in most cases if you can prove that you can also write your system to use only static allocations.

fiddlerwoaroof 10y ago

Even in the flat structure case, doesn't reference counting turn referencing an object into a synchronization point? For example if I try to use several threads to make a million objects reference a single object, I'll have to lock every time I add a reference, reducing parallelism.

openasocket 10y ago
Well yes and no. In the multi-threaded case you'd use ARC (atomic reference count) pointers. These use atomic instructions to increment and decrement references, and are thus lock-free. There's still contention, but only on the data bus and the cache coherency protocol for the atomic instructions. Under contention, you're looking at latency for access less than 80-100ns. Of course, if all of these threads are accessing an object at once you're going to have contentions no matter what, unless all of the threads are read-only.
kazinator 10y ago
Reference counting is a form of GC. It has nondeterministic delays. You don't know which dropref() operation will just decrement and which will finalize. Moreover, when refcounted objects finalize, they recursively drop the refs they hold. Of course, in some trivial cases it is obvious. But in those cases, you could use manual memory management. For instance, trivial case: making an object and then dropping it in the same scope.
- dllthomas 10y ago
  > Moreover, when refcounted objects finalize, they recursively drop the refs they hold. You can (at the cost of some additional complication) make this more deterministic by adding newly-dead objects to a "finalize this soon" queue and chewing through that when you have time (or on a different thread).

adrianN 10y ago

Do hard real time systems discourage dynamic memory because historically there were no systems that could provide real time guarantees or because of some theoretical barriers? I think it's the former.

openasocket 10y ago
There's other issues. Like the fact that you could run out of memory and allocation fails. Then what do you do? For hard real time systems crashing isn't acceptable, so you have to continue on, but assuming you actually needed that data you tried to allocate that's not going to be easy. So you need to prove your system won't ever allocate too much memory. That's pretty hard to do, and in most cases if you can prove that you can also write your system to use only static allocations.