Re: An accurate, pauseless & deterministic GC for C++
"Mingnan G." <lelandguo@yahoo.com.cn> wrote in message
news:5a2620ce-6cfe-4d37-bcc2-76373b9d85b1@s36g2000prg.googlegroups.com...
On Nov 26, 10:20 am, "Chris Thomasson" <cris...@comcast.net> wrote:
- I notice that the _hnxgc_assign_lptr function is made up of more than
an
interlocked update, or simple distributed reference count increment. I
notice at multiple lines of code that makes calls into other object
functions made up of multiple lines of code themselves.
[...]
Note: assign a CLockedPtr to another CLockedPtr will not cause any
RC operation, so will not execute the _hnxgc_assign_lptr function.
I give an example, suppose two pointers: 'p1' points to 'A', 'p2'
points to 'B',
'p1' is a CLockedPtr pointer, then considering the following C++
statement:
p1 = p2;
(1) if 'p2' is alos a CLockedPtr pointer, then there is no RC
operation, no
calling to _hnxgc_assign_lptr function.
(2) if 'p2' is other type of pointer, such as CWeakPtr, CMemberPtr,
then the
_hnxgc_assign_lptr is called. It will complete following works:
a. increment the RC of object 'B';
b. decrement the RC of object 'A'.
c. set the pointer 'p1' pointing to 'B';
- I notice that the _hnxgc_assign_mptr function has more lines than
_hnxgc_assign_lptr, and it does make calls to functions made up of
multiple
lines of code.
the situation _hnxgc_assign_mptr is like _hnxgc_assign_lptr. It also
include a
RC decrement and a RC increment operation.
Thank you for that information Mingnan as it help me understand what's going
on much better. Okay, so I think what you are saying is that CLockedPtr
provides the strong thread-safety level and the following pseudo-code would
be legal if the refcount object was replaced with CLockedPtr:
_____________
static refcount<foo> g_foo(new foo);
threads_a_x() {
for(;;) {
refcount<foo> l_foo(g_foo);
if (l_foo) {
l_foo->foo();
}
}
}
threads_y_z() {
for(;;) {
refcount<foo> l_foo(new foo);
g_foo = l_foo;
}
}
______________
This example will not work if the implementation of refcount does not have
the strong thread-safety guarantee. Refer to the following thread for far
more details of what I am getting at here:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/e5167941d32340c6
Can I do lock-free programming with your smart-pointers? Refer to the
following post for more info:
http://groups.google.com/group/comp.lang.c++/msg/eada4a93d932430e
Is that a legal programming style within the scope of your GC?