From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-12-09 12:53:14
On Thu, Dec 09, 2004 at 09:32:05AM -0800, Dayton 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<>?
FYI I've modified boost::shared_ptr for inclusion in GCC's standard
library and have replaced the mutexes with atomic ops along those lines.
(I've finished the changes but am trying to find time to write extensive
tests for the libstdc++ testsuite before I add the code to GCC's CVS
repository. I was warned on this list that the tests take the most work :)
-- "It is always the best policy to tell the truth, unless, of course, you are an exceptionally good liar." - Jerome K. Jerome
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk