Re: Could the memory order be relaxed in the implementation of std::shared_ptr?
187 views
Skip to first unread message
Message has been deleted
Nicol Bolas
Jun 25, 2017, 12:01:25 AM6/25/17
to ISO C++ Standard - Future Proposals
On Saturday, June 24, 2017 at 11:35:23 PM UTC-4, Mingxin Wang wrote:
If you're referring to the semantics of the atomic decrement, I'm fairly sure that's required by the standard. Without that acquire/release increment, consider what happens if two shared_ptrs to the same object are being destroyed on two separate threads.
Thread 1 sets some non-atomic state, then destroys its `shared_ptr`. If that `shared_ptr` is the last pointer, then the destructor will be able to see the non-atomic state that was set, since the destructor will run on this thread. So logically, Thread 1 is saying that the non-atomic state setting "happens before" the object being destroyed.
But what if it wasn't the last pointer? The last pointer is on Thread 2, which destroys the object later. Without the acquire/release, none of those changes on Thread 1 will "happen before" the destructor being called in Thread 2.
So I would say that the acquire/release is not optional.
After analysing the implementation of std::shared_ptr in GCC (6.3), I found there is a synchronization in its destructor (not required in the standard),
If you're referring to the semantics of the atomic decrement, I'm fairly sure that's required by the standard. Without that acquire/release increment, consider what happens if two shared_ptrs to the same object are being destroyed on two separate threads.
Thread 1 sets some non-atomic state, then destroys its `shared_ptr`. If that `shared_ptr` is the last pointer, then the destructor will be able to see the non-atomic state that was set, since the destructor will run on this thread. So logically, Thread 1 is saying that the non-atomic state setting "happens before" the object being destroyed.
But what if it wasn't the last pointer? The last pointer is on Thread 2, which destroys the object later. Without the acquire/release, none of those changes on Thread 1 will "happen before" the destructor being called in Thread 2.
So I would say that the acquire/release is not optional.
Reply all
Reply to author
Forward
0 new messages