Re: Atomic Reference Counting - Do you think this would be useful to Boost?
Chris Thomasson wrote:
"kanze" <kanze@gabi-soft.fr> wrote in message
news:1160641223.253521.56670@m73g2000cwd.googlegroups.com...
Earl Purple wrote:
Chris Thomasson wrote:
Currently, Boost doesn't provide support for "true"
atomically thread-safe atomic reference counting:
[...]
Does anybody think that Boost could make use of this level of
thread-safety?
[...]
shared_ptr doesn't have the semantics you want when passing
objects accross threads.
I also think that shared_ptr<...> does not provide efficient,
or any?, support for strong/atomically thread-safe competing
ref-count increments from multiple threads in parallel;
It could, if there were any reason for it to. I think there's
an issue of cause and effect here: the semantics of shared_ptr
are inappropriate for objects shared between threads, so there's
no real use in making it "thread safe".
I don't think the following contrived scenario is valid with
shared_ptr<...>. Please correct me if I am wrong:
(pseudo-code)
static shared_ptr<app> g_app(new app(...))
static shared_ptr<foo> g_foo;
void a_number_of_threads() {
for(...) {
// I don't think the following is atomic in current shared_ptr<...>:
shared_ptr<foo> l_foo(g_foo);
I can't see any reason why it should be. I can't imagine any
use where it wouldn't lead to a programming error later.
There might be some vague argument concerning
shared_ptr< foo const >, but I can't think of any realistic
situations where it would be appropriate (just as a I cannot
think of any realistic cases where you would have a shared_ptr
with static lifetime). The fact that I can't think of them
doesn't mean that they don't exist, of course, but it sort of
makes me think that they are at least rare enough that the
committee needed waste too much time on them.
if (l_foo) {
if (l_foo->some_predicate(...)) {
shared_ptr<foo> n_foo(new foo(...));
n_foo->local_update(l_foo);
// I don't this cas is even possible in current shared_ptr<...>:
if (! g_foo.cas(l_foo, n_foo)) {
n_foo->local_rollback(l_foo);
g_app->log_rollback(l_foo, n_foo);
}
}
l_foo->some_real_processing(n_foo);
} else { g_app->some_other_processing(...); }
}
return 0;
}
What you need is auto_ptr.
Regretfully, there's no way of getting an auto_ptr from a
shared_ptr. (On the other hand, I've never had any problem with
auto_ptr's semantics in this case, using raw pointers for
weak_ptr's. Perhaps a weak_ptr for auto_ptr would be the
answer.)
Once you have "pure" word-based atomic ref-counts, you can
apply normal word-based atomic operations (e.g., CAS, SWAP; no
DWCAS needed) directly to shared locations that hold a pointer
to a ref-count object. So, in order to get lock-free
auto_ptr<...> like semantics with them you could do something
like this contrived scenario:
foo *raw = new foo(...);
atomic_lptr<foo> l_foo(raw);
atomic_sptr<foo> s_new_owner;
// a lock-free transfer-of-ownership from l_foo to s_new_owner
s_new_owner.swap_weak(l_foo, 0);
// l_foo is invalid; if it's non-null we can use it if it does not point to
raw!
if(l_foo && l_foo != raw) {
// we have gained ownership of a new object that we did not create.
}
An example implementation of a lock-free
s_new_owner.swap_weak(...) function, in IA-32 Assembly, can be
found here:
Again, I'm not really convinced. Most of the time, anyway, you
need to inform the other thread that the object is available,
either putting it in a queue, so the other thread can pick it up
later, if it is busy, or unblocking the other thread, if it was
already waiting. There are probably more exceptions to this
than to the former case, but again, I'd really like to hear
about some non-contrived scenarios.
[...]
Any thoughts?
For the moment, I have the impression that I'm seeing solutions
looking for a problem. Maybe in some domain I'm less familiar
with?
--
James Kanze (Gabi Software) email: kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]