And C++'s hideous shared_ptr system isn't a good thing to point to.
Single ownership with weak references is effectively what you have in C, though I guess compiler support for distinguishing which references are weak or strong is nice.
For refcounting and real-time, just let me leak the cycles. The non-realtime part of reference counting is the cycle detection, let me control the cycle sweeps and everybody's happy.
Maybe you are happy, but 99.9% of people would probably be very unhappy with that solution. How would you even go about accomplishing that in a way that wouldn't make you lose your mind? I can only imagine the complexity of having to decide how many cycle sweeps need to be done every time I reduce the reference count on an object/struct. I also think the runtime performance of enforcing that kind of limit would out way any possible benefit.
Consider a soft real-time environment like a game. Under RC, the time required to render a single frame depends only on the work done in that frame. Get it to 16 ms and you're done. But under GC, deallocation work can accumulate. A frame that would otherwise render in 16 ms may take much longer, due to the laziness of previous frames. That makes it harder to optimize, and indeed you'll often see advice like "frames must do zero GC allocations." Yikes!
Things may be different in hard real-time systems, which I know use specialized allocation schemes optimized for worst-case latency instead of bandwidth.
[1]Google has pdf. BTW, how do i extract a long living pdf link from a google link ?