On Thu, 09 Dec 2004 09:32:05 -0800, Dayton <mvglen04-cnews@yahoo.com> wrote:
Shared_ptr<> down deep uses a light-weight mutex to protect the increment and decrement of its reference count. A mutex isn't needed here. A mutex may yield the context of execution. This seems silly to protect a single instruction.
To support threads, all modern processors offer some form of interlocked operation or atomic compare-and-swap instruction. On SPARC cpus, it is the CAS instruction, which acts much like a spin-lock. Windows offers InterlockedIncrement() and InterlocledDecrement() functions, which in the newer Microsoft compilers may be compiled as an intrinsic.
I'm a bit allergic to context yielding synchronization objects thrown randomly into my server code. Does anyone know of any reasons to not use CAS-style programming here before I propose using it for smart_ptr<>?
Glen
This should probably be a FAQ. I'm sure there are lots of messages in archive about this. Peter Dimov, or one of the Peters, I think has such an interlocked implementation which you'll find referred to in the message archive. Though the issue, from memory, is that there are two counts, for the weak and "strong" references and a lightweight mutex is about the same cost as two interlocked or CAS style ops so there is not necessarily a big benefit in changing. Explicit, yielding is a bad thing though... However, this leave the shared_ptr as a slowish pointer in a multithreaded environment if that is important to you. Even in a multithreaded code base you often want a fast single threaded smart pointer for appropriate situations, the current shared_ptr is not appropriate here either. A policy based design should allow you to customise these decisions as Loki's smart pointer shows. I think David Held is the closest to a reification of this abstraction for boost. There are many issues with policy based designs, especially without template typedefs in the language and w.r.t. compatibility, that have been discussed in the past, which is why the current shared_ptr interface design is perhaps the best common denominator to be useful to the widest audience. We are better with it than with arguing endlessly about the best approach... Another thought is to be aware that the count can be wrong sometimes and the semantics can still work. Researchers have used this to make faster reference counting work. That is, it doesn't matter if your count is wrong and too high, all that really matters is that someone gets a zero when the references are eliminated. I can probably dig out a reference to the paper I'm thinking of, if anyone is interested... You also raise an interesting point that as well as having correctness unit tests, boost should probably have performance benchmarking unit tests for libs where appropriate as performance needs to be checked and monitored for many lib components. HTH, matt matthurd@acm.org