Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
14 Views

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

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:
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! ;)
0 Kudos
2 Replies
Highlighted
New Contributor I
14 Views



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.
0 Kudos
Highlighted
New Contributor I
14 Views

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:
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
0 Kudos