ref_ptr causes crash in multi-thread environment

[HugeRoll]

Describe the bug
I've encountered a crash issue, and after investigation, I found it's related to incorrect reference counting of ref_ptr in a multi-threaded environment.

To Reproduce
Steps to reproduce the behavior:
Threads A and B will both reference and create ref_ptr for the target object named myObj, and then destroy the ref_ptrs they created after several steps.
The crash scenario can be chronologically simplified as follows:

1. thread A, myObj->ref(), _referenceCount.fetch_add, then _referenceCount is 1.
2. thread A, myObj->unref(), _referenceCount.fetch_sub, then _referenceCount is 0.
3. thread B, myObj->ref(), _referenceCount.fetch_add, then _referenceCount is 1.
4. thread A, myObj->unref(), attemptDelete, _ptr becomes a hang-pointer.
5. thread B, using myObj, although its _referenceCount is not 0, its _ptr is a hang-pointer, CRASH!

Other scenerio
I've also encountered cases of incorrect object destruction. When I capture a ref_ptr by value in a lambda expression and add it to Viewer's update operation queue, there is a chance that the object managed by the ref_ptr is destructed before the lambda is executed. I think it is a same bug.

Expected behavior
If ref_ptr is enabled for multi-threaded environments, I think its reference counting operations should​ be thread-safe. We can use mutex or atomic operations (like Compare-And-Swap) to ensure that. And it would be more safe when Lambda functions capturing ref_ptr by value.

[robertosfield]

The vsg::Object uses an atomic reference count explicitly to ensure it's safe to use with ref_ptr<> in a threaded applications. The was built directly into the VSG right at the start of the project back in 2018 and has been used in threaded applications since.

This doesn't mean that it's not possible create a threaded application that use the VSG and still have threading bugs that make it look like it's a reference counting issue, but there are many ways to create race conditions in threaded application, atomic reference counting only solves a very small part of the challenge.

All I know from you explanation is you've created some custom threaded code that exhibits a crash that you have interpreted as an issue with the reference count. You haven't provided any example code that illustrates your usage case so there is no way for us review what you are doing and determine whether it's safe, or to run that code and determine where the problem might be.

The best thing you can do is create a small test program along with a CMake build support so that others can check out the problem, reproduce it, then review the code to see if it's actually sensible and provide feedback. If there is an actual bug on the VSG side then we can look into this.

It's also really helpful to provide information about the hardware, OS and build tools that you are using.