Re: An accurate, pauseless & deterministic GC for C++
On Nov 29, 3:29 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
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/th...
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?- Hide quoted text -
- Show quoted text -
Yes, I think it is okay for this example. But lock-free programming in
HnxGC application should be with very cautions, the lock-free (non-
blocking) feature of HnxGC just means that pointer assignment in
application mutator threads is lock-free with backgound concurrently
running collector thread. Correct lock-free mechanism *between
application threads* as in this example is the responsibility of
application program not HnxGC collector. We don't provide extra lock-
free mechanism above traditional C/C++ programming for application.
Accessing a shared resource normally should under some synchronization
mechanism protection, e.g. mutex, unless you deliberately act without
lock for performance.
For illustration, I modified your example a little as following:
--------------------------------------------------
// atomically shared with multiple threads (it should be on nature-
boundary address, e.g. 4 byte for 32-bit platform)
static void * volatile g_foo = NULL;
threads_a_x() {
for(;;) {
lp<CFoo> l_foo;
l_foo.attach(g_foo); // read atomically from 'g_foo'
if (l_foo) {
l_foo->foo();
}
}
}
threads_y_z() {
for(;;) {
lp<CFoo> l_foo = gcnew CFoo;
void *p = l_foo.detach();
// write to 'g_foo' with racing
if(atomicCompareAndSwap(g_foo, 0, p) != 0) {
// failed, restore to 'l_foo' to reclaim this object
l_foo.attach(p);
}
}
}
-----------------------------------------
Actually, if an application maintains consistency of reference
relationship before and after an reference operation, the operation
can be invisible to HnxGC collector and it is free to use any multi-
threading mechanisms as you like. The "moving reference" mechanism in
HnxGC Smart Pointer is also an example, refer to the following link
for more details:
http://hnxgc.harnixworld.com/algo_refcount.htm ,
and
"Assignment between 2 CLockedPtr" in http://hnxgc.harnixworld.com/prog_b03.htm