Subj : Re: A question about atomic_ptr To : comp.programming.threads From : Joe Seigh Date : Mon Apr 11 2005 02:10 pm On Mon, 11 Apr 2005 15:40:30 +0300, Peter Dimov wrote: > Joe Seigh wrote: >> >> As a practical matter I don't think you're going to have have more >> than one local pointer copy of a global shared pointer often enought to >> justify the extra overhead of maintaining a separate reference count >> and of the extra indirection. > > You may well be right. It's just one idea for a possible extension of > shared_ptr that could pacify the "we want our unsynchronized pointers" > portion of the "C++ community". I'm not sure yet whether it's a _good_ idea. > > There's a bit of a learning curve here. I don't think the general programming community has enough experience in multi-threaded programming, compared to the experience we have here in c.p.t, to have a good feel for all the issues yet. For example, when you're doing reference counting in a single threaded program, you don't need to distinguish between read access and write access. But when you start using multi-threading, the performance implications of distinquishing between read and write access become more important, which is why I've been emphasizing smart pointers as a solution to the readers/writers problem rather than a generic resource management tool. There seems to be some attraction in c.l.c++.m to smart pointers that have almost no overhead, the deferred reference counting being promoted by Andrei but there's no such thing a a free lunch. Deferred reference counting does Boehm style GC against the thread stacks and that requires a "stop the world while we GC" which has huge performance implications in multi-threading. We're well aware of the problem of checking or monitoring threads local references. That's what makes RCU or SMR so tricky. If there was an easy way around it, we'd be using it. There isn't. What you have is a bunch of different techniques with different trade-offs. What you do is use the one that gives you the most benefit depending on the situation. There won't be one size fits all. What you will want to do for Boost is allow different smart pointer techniques for the time being until multi-processor systems become ubiquitous enough that everyone has a feel for the issues. Then you can start winnowing the smart pointers down. But I don't think you will have one grand unified smart pointer. I've been at this for a while and I'm not willing to discount any of current techniques yet. Even the ones I didn't invent. :) -- Joe Seigh .