Subj : Re: full-blown experiential smr-based reference counted pointer impl...
To   : comp.programming.threads
From : Chris Thomasson
Date : Tue Apr 05 2005 08:28 pm

> If you have a runtime environment that you have control over then you can
> define the quiescent states in it.  You can't do that with a standalone
> RCU.  If you define the quiescent states elsewhere, it has to be 
> understood
> that you're restricted from using functions that have quiescent states
> in your RCU critical regions for that particular RCU implementation.

Yes. The docs for my implementation have a rather thorough section on 
"Garbage Collected Region Management". Particularly how a region can be 
invalidated by calling functions that contain a quiescent state:


qs_function()
{
  // if per_thread is rcu_acquired, swing to quiescent

    // do whatever

  // swing per_thread back to previous state
}


// acquire rcu

  // gc region 1

  qs_function();

  // gc region 2

// release rcu


The call to gc_function incremented the calling threads garbage collected 
region from 1 to 2 by forcing an explicit quiescent state. The docs explain 
how the local pointers that were pointed to objects that "existed" in region 
1 will produce undefined behavior if they are accessed in region 2. The docs 
recommend that a thread should set all of its local object pointers read 
from the shared pointers protected by region 1 to NULL before calling any 
function that may contain a quiescent state and/or increment the actual 
current garbage collected region or its generation. It also recommends that 
functions that alter the quiescent state of a thread in anyway, shape, or 
form should be heavily documented as doing so...


Also the calls to "// acquire rcu" functions are recursive:


So you can do stuff like this:


/* contains explicit quiescent state */
qs_function()
{
  // if per_thread is rcu_acquired, swing to quiescent

    // do whatever

  // swing per_thread back to previous state
}


/* only acquires the current garbage collected region */
safe_function()
{
  // acquire rcu

    // do whatever

  // release rcu
}


// acquire rcu

  // gc region 1

  safe_function();

  // still in gc region 1

  qs_function();

  // gc region 2

// release rcu


The call to safe_function did not alter the calling threads collection 
state.




This stuff may be too complicated for and end user that is inexperienced 
with proxy garbage collection to grasp. The docs clearly explain how you 
can, and will, crash your application "real easy" if you do not know what 
you are doing. Humm...

.