Re: If GC is the solution, then what is the problem?
Joe Seigh wrote:
Andrei Alexandrescu (See Website For Email) wrote:
Sorry, my point was different. I was referring to the cases in which
smart pointers perform _unneeded_ synchronization. Smart pointers lack
the horizon to know when they are at risk and should synchronize, or are
safe and don't need to. So they always synchronize.
Well, my main use of smart pointers is for the multi-threaded environment
and I seem to have no problem avoiding unnecessary synchronization so
I don't understand where you think unnecesary synchronization is taking
place and why it can't be avoided.
Reference-counting smart pointers synchronize the increment and
decrement operations on the reference count. Unnecessary synchronization
occurs when all smart pointers to an object belong to the same thread.
You can't avoid it unless you customize your smart pointers with
separate policies for single-threaded reference counting and
multithreaded reference counting, and use them accordingly.
But you don't know what I'm thinking of :o). Anyhow, referring us to
credible experiments would always help.
Maged Michael's SMR hazard pointers don't need interlocked instructions
for read access. I've combined it with a modified version of RCU to
eliminate the need for memory barriers. #StoreLoad type memory barriers
are very expensive. It seems to run about 2 to 4 times the speed of
a plain load. It's PDQ. The code used to be on my project page but
is no longer there due to various patent issues.
So you agree with me: it's not trivial.
They can be as hard as years of research, as has happened. In contrast,
Java has lock-free components in its standard library now.
They had to wait for JSR-133 and JSR-166 first.
The nice part is, we don't :o).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]