Artyom wrote:
Take a look on following two files:
sp_counted_base.h
You don't need the mutex. Look at the recent sp_counted_base_spin.hpp.
sp_counted_base.cpp http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/branches/refactoring/booster/lib/smart_ptr/src/sp_counted_base.cpp?revision=1185&view=markup
No need to use atomic_set in the constructor. If your constructor races with another member, atomics won't save you.
It is the only class I had to change in boost-shared ptr to make it ABI stable.
How did I this?
1) I moved implementation to library 2) I added pthread_mutex_t to the class even if I do not use it. 3) I removed debug hooks.
Now what happens:
1. I can change the implementation of the counter - use atomic-ops assembly or OS specific operations without warring about compatibility because all operations are done in single library. 2. I can add atomic operations on platforms where they were not availible before without changing layout of class - just by stopping using pthread_mutex_t.
What does it requires?
1. Linking against some core library. 2. Little thinking about what can happen.
With all due respect, may I submit that the reason it was so easy to make shared_ptr ABI-stable was that it was designed with this in mind? shared_ptr was frequently criticised for having too much overhead and being too slow, and it was an intentional design decision to allow add_ref/release to be inlined. I knew that on most relevant architectures this didn't provide any significant performance benefit (even making them virtual is affordable - and this is another interesting tradeoff, allowing ABI-incompatible shared_ptr instances to coexist), but C++ programmers are notoriously picky. Besides, Boost was entirely header-only at the time shared_ptr was first designed and implemented, and had no build system. In any event, the ABI-stable shared_ptr is spelled std::shared_ptr.