I wonder if I’m doing something wrong.
I’m making an object and assigning it right to a refcountedPtr. I then pass it around as a refcountedPtr - I just use the template class in my method declarations.
I’m getting asserts and crashes with dec < 0. Two possibilities, one is that my user classes can’t access the refcountedPtrs properly in declarations.
The other is that it’s being decremented on two threads at once, somehow.
Any ideas?
Bruce
the reference counting should be thread-safe, so I guess you must at some point be accidentally holding a normal pointer to the object while all the ref-counted pointer objects go out of scope. Surely it’s quite easy to find where the object gets deleted, and then look for the next time a pointer to it is used?
Well, I looked and looked. I never have a pointer to it - everything is a refcountedptr.
I’m going to guess that refcountedarray has an error. At a brief glance, you decrement a removed object before you remove it. In my mind, that means another thread could access it before it’s removed.
Is this class not thread-safe? Can I somehow use an owned array, maybe with refcountedPtrs and a CriticialSection? Or could refcountedarray be thread-safed?
Bruce
Ah - now I never said that the RefCountedArray was thread-safe, I just meant the pointers themselves! I should probably add some critical section code to it like for the other arrays, TBH…
Is that quick, or should I try to re-use an ownedarray? Is that even possible, templates in templates?
Bruce
Hmm, what would I need? An array of pointers to refcounted ptrs? Or own an array of refcountedPtrs? Sheesh.
Yes, an owned array of refcountedptrs seems to work so far. I feel like I lost some safety though, since I have to do a :
if size > index
return MeshFrame::Ptr(*myArray[index])
The array, in theory, could drop in between the test and return.
Bruce
That should be fine, though if I were you, I’d just use a critical section around the code that accesses the array. That’d be neater, and less prone to errors.
