"David Abrahams" <dave@boost-consulting.com> wrote in message news:<8764o1azuq.fsf@boost-consulting.com>...
"David Maisonave" <dmaisonave@commvault.com> writes:
IIUC, the thread-safety problem with reference-linked implementation isn't that so much that it's hard to achieve -- anyone can use a shared mutex -- it's that it's hard to make a thread-safe implementation efficient. That is to say, you pay for the cost of locking and unlocking a mutex, and there's no way around it (**). Locking and unlocking mutexes is way more expensive than performing the lock-free operations used by boost::shared_ptr.
That's true. But it's been my experience that the majority of development don't have objects access via multiplethreads or don't run in a multithread environment. In this environment, you're paying additional price for using boost::shared_ptr reference-count logic, but not getting any benefits from it.
Not if you're compiling without mt support on; the thread safety features of shared_ptr just compile away (and I think there's a macro you can use to force them off). Let's compare apples to apples: your reflinked implementation will be slower in a MT environment. I'm not yet convinced it will be faster in a ST environment unless you leave the MT features of shared_ptr turned on.
Currently, my test results don't support your above comment. Please provide the this macro you're referring to. Without this macro, there's no way of testing your claim.