Re: why boost:shared_ptr so slower?
Sam wrote:
Pete Becker writes:
Juha Nieminen wrote:
Pete Becker wrote:
Juha Nieminen wrote:
Increments and decrements are in no way guaranteed to be atomic, and
in some architectures they may well not be. Even if they were, there's
still a huge mutual exclusion problem here:
if (! --m_ptr->m_count) {
delete m_ptr;
}
Guess what happens if another thread executes this same code in
between the decrement and the comparison to null in this thread,
and the
counter happened to be 2 to begin with.
If the decrement is atomic (not an atomic CPU instruction, but
atomic in
the sense of not tearing and producing a result that's visible to all
threads that use the variable) then this works just fine. Of course,
all
the other manipulations of this variable must also be similarly atomic.
I don't understand how that can work if the result of the decrement is
not immediately visible to all threads.
Which is why I said "producing a result that's visible to all threads..."
gcc manual, section 5.47, under the description of atomic functions,
states the following:
In most cases, these builtins are considered a full barrier. That is,
no memory operand will be moved across the operation, either forward or
backward. Further, instructions will be issued as necessary to prevent
the processor from speculating loads across the operation and from
queuing stores after the operation.
I interpret this as stating that the results of these atomic functions
will be immediately visible to all other threads.
There are ways to implement fully atomic accesses to data objects,
including guaranteeing visibility. What I was responding to was your
assertion (which has disappeared from the history):
>> The actual
>> increment/decrement operations are the same as with shared_ptr --
>> compiler-specific instructions that compile down to atomic CPU
>> operations, so that they are thread-safe.
Using "atomic CPU operations" is not sufficient, in general. Some
platforms might support them, but others don't.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)