full-blown experiential smr-based reference counted pointer impl...

[Chris_M__Thomasson]

I have implemented an experimental reference counted pointer C api based on SMR. I also includedtwo extremely quick and dirty atomic C++ smart pointer classes that are based on the reference count api. Its basically just a proof of concept. There is a MSVC++ 6.0 workspace and two Dev-C++ projects included, so you can buildAppCore on Windowsright away. The projects build the appcore.dll in the c:/winnt/system32 directory, so you may need to change this to fit your needs:

http://appcore.home.comcast.net/appcore_3_30_2005.zip

I am currently working on Linux build instructions. You basically need to assemble the ac_i686_gcc.asm files and link against the resulting object file.

Any questions and/or comments on smr-based reference counted pointers?

Enjoy! ;)

[Chris_M__Thomasson]

---

Any questions and/or comments on smr-based reference counted pointers?

---

You could use the logic to create a simple atomic COW buffer like this:

// buffer is assumed to be an efficent thread-safe buffer...
typedef local_smr_ptr< buffer > local_bufptr_t;
typedef shared_smr_ptr< buffer > shared_bufptr_t;

// shared
static shared_bufptr_t g_buf( new buffer( "init" ) );

// COW /w CAS
local_bufptr_t cmp, xchg( new buffer );

do
{ cmp = g_buf;
cmp->copy_to( xchg );
xchg->append( " updated via. CAS" );
} while ( ! g_buf.cas( cmp, xchg ) );

// COW /w XCHG
local_bufptr_t xchg( new buffer ),
cmp( g_buf );

cmp->copy_to( xchg );
xchg->append( " updated via. XCHG" );
g_buf.xchg( xchg );

Or you could use the SMR pointer to create robust synchronization objects
that will never be destroyed if there any threads that have references to
them:

// mutex is assumed to be an efficent mutex...
typedef local_smr_ptr< mutex > local_mutexptr_t;
typedef shared_smr_ptr< mutex > shared_mutexptr_t;

// shared
static shared_mutexptr_t g_mutex( new mutex );

// Lock/Unlock
local_mutexptr_t l_mutex( g_mutex );
if ( ! l_mutex ) { return; }
l_mutex->lock();
// whatever
l_mutex->unlock();

The smr atomic pointer has an expensive (store/load) before the reference
count can even be incremented. So, its a fairly costly when you load a
shared pointer into a local pointer. You would not want to use this for
everything.

[Chris_M__Thomasson]

I noticed that I was not aligning the per-thread hazard pointer
data-structures on separate cache-lines!!! This is not a bug, it is just a
fairly major performance issue... You should probably re-download:

http://appcore.home.comcast.net/appcore_4_1_2005.zip

Aligning the per-thread SMR data-structures on separate cache-lines shaves
off an average of 2 - 3 seconds of runtime from nearly all of my tests!

Sorry! :O