Thread Safety of ReferenceCountedObjectPtr

General JUCE discussion
1

I am a bit confused regarding the thread safety in ReferenceCountedObjectPtr. From what I can read in docs its saids that pointers (ReferenceCountedObjectPtr?) to ReferenceCountedObject objects "can be passed between threads safely".

I understand that ReferenceCountedObject has an atomic counter and access to this counter is thread safe.

However I do not understand how ReferenceCountedObjectPtr can be passed safely between threads since the call to atomic increment of ReferenceCountedObject is not thread safe.
 

    static void incIfNotNull (ReferencedType* o) noexcept
    {
        if (o != nullptr)
            o->incReferenceCount();
    }


Here o might be deleted by another thread after the if statement and before the ++refCount state in ReferenceCountedObject, making o corrupt before atomic increment.

The way I read the code is that the ++refCount is an atomic operation, but everything around it is not and therefor ReferenceCountedObjectPtr is not thread safe.

Is this the correct interpretation or am I missing something here?

Stack Overflow question on the same topic

http://stackoverflow.com/questions/8007186/read-write-thread-safe-smart-pointer-in-c-x86-64

2

Obviously it's not safe to pass a bare pointer to another thread and then call incIfNotNull on it, but if you only pass the object via ReferenceCountedObjectPtr wrappers, then incIfNotNull will only ever be called in a situation where the caller already holds a reference, so it'd be impossible for another thread to free it.

3

I think I understand now.

A thread X must not create a ReferenceCountedObjectPtr to an object that only has a ReferenceCountedObjectPtr in another thread Y (race condition I mention), but if thread Y creates a ReferenceCountedObjectPtr and passes it to thread X, then its safe and the refCount will remain correct across the threads because of the atomic refCount.

So each thread must have its first ReferenceCountedObjectPtr to an object passed to it and afterwards it is thread safe to create additional / remove ReferenceCountedObjectPtrs.

4

Can't understand your first paragraph, but the TL;DR is that as long as you use ReferenceCountedObjectPtr instead of bare pointers, it should all be fine.