A real threaded singleton

[EvilOldGit]

In the stuff I've read about multi threaded singleton it seems to
assume that creating the Lock is atomic, and various sources,
including Sutter go for RAII.
{
Lock l;
if ( ! inst )....
}
But I don't see how to do this with a real O/S API.
The ones I've looked at have a two step process to making a lock, they
require a "Create" function and a "Start Locking" function.

A Lock class is presumably implemented as something like:
class Lock
{
private :
PrimitiveLockTy pe PrimitiveLock;
PrimitiveHandle handle;
public:
Lock() {
PrimitiveLock = CreatePrimitive Lock():
handle = StartLocking (PrimitiveLock) ;
}
~Lock()
{
StopLocking(han dle);
KillPrimitiveLo ck(PrimitiveLoc k);
}

};

Now if I have two threads there is a chance (albeit a small one) that
I end up creating two PrimitiveLocks

Thus far, I've got around it by making the PrimitiveLock a global
static like the Instance member.
That makes error handling awkward, though if this is failing at such
an early stage then the program's not likely to work anyway.
What am I missing ?


}

[Chris Thomasson]

<Ev********@goo glemail.comwrot e in message
news:11******** *************@n 76g2000hsh.goog legroups.com...

In the stuff I've read about multi threaded singleton it seems to
assume that creating the Lock is atomic, and various sources,
including Sutter go for RAII.

There is a solution for a thread-safe version of that here:

http://groups.google.com/group/comp....da701564880ab4

http://appcore.home.comcast.net/vzdo...c/static-init/

http://appcore.home.comcast.net/vzoom/refcount/

You use a hashed-mutex/spinlock scheme to handle atomic lock
construction/destruction. e.g.:

// Details
#define DETAIL_CONCATX( __t1, __t2)__t1##__t2
#define DETAIL_CONCAT(_ _t1, __t2)CONCATX(__ t1, __t2)

#define DETAIL_HASHMUTE X_8(__init)\
__init, __init, __init, __init, __init, __init, __init, __init

#define DETAIL_HASHMUTE X_32(__init)\
DETAIL_HASHMUTE X_8(__init), DETAIL_HASHMUTE X_8(__init),\
DETAIL_HASHMUTE X_8(__init), DETAIL_HASHMUTE X_8(__init)

#define DETAIL_HASHMUTE X_128(__init)\
DETAIL_HASHMUTE X_32(__init), DETAIL_HASHMUTE X_32(__init),\
DETAIL_HASHMUTE X_32(__init), DETAIL_HASHMUTE X_32(__init)

#define DETAIL_HASHMUTE X_256(__init)\
DETAIL_HASHMUTE X_128(__init), DETAIL_HASHMUTE X_128(__init)

#define DETAIL_HASHMUTE X_512(__init)\
DETAIL_HASHMUTE X_256(__init), DETAIL_HASHMUTE X_256(__init)

#define DETAIL_HASHMUTE X_CONCAT(__init , __count)\
DETAIL_CONCAT(D ETAIL_HASHMUTEX _, __count)(__init )
// Impl
#include <pthread.h>

#define HASHMUTEX_DEPTH () 256
#define HASHMUTEX_INITI ALIZER() PTHREAD_MUTEX_I NITIALIZER

#define HASHMUTEX_PTR(_ _ptr) (((int)__ptr) % HASHMUTEX_DEPTH ())

#define HASHMUTEX_STATI CINIT() {\
DETAIL_HASHMUTE X_CONCAT(HASHMU TEX_INITIALIZER (), HASHMUTEX_DEPTH ())\
}

// hashed-mutex table
static pthread_mutex_t hashmutex_table[
HASHMUTEX_DEPTH ()
] = HASHMUTEX_STATI CINIT();

static int hashmutex_lock( void* const ptr) {
return pthread_mutex_l ock(&hashmutex_ table[HASHMUTEX_PTR(p tr)]);
}

static int hashmutex_trylo ck(void* const ptr) {
return pthread_mutex_t rylock(&hashmut ex_table[HASHMUTEX_PTR(p tr)]);
}

static int hashmutex_unloc k(void* const ptr) {
return pthread_mutex_u nlock(&hashmute x_table[HASHMUTEX_PTR(p tr)]);
}


class A {};
class B {};

static A g_a;
static B g_b;
int main() {
// lock & unlock a
hashmutex_lock( &g_a);
// ...
hashmutex_unloc k(&g_a);

// lock & unlock b
hashmutex_lock( &g_b);
// ...
hashmutex_unloc k(&g_b);
return 0;
}

Got to watch out for deadlocks... Here is one possible solution:

http://groups.google.com/group/comp....011baf08844c4/

Any thoughts?
:^)

[James Kanze]

On Apr 9, 7:23 pm, EvilOld...@goog lemail.com wrote:

In the stuff I've read about multi threaded singleton it seems to
assume that creating the Lock is atomic, and various sources,
including Sutter go for RAII.
{
Lock l;
if ( ! inst )....}

But I don't see how to do this with a real O/S API.

The ones I've looked at have a two step process to making a lock, they
require a "Create" function and a "Start Locking" function.

Any real answer will depend on the OS. Normally, you should be
able to create and initialize a mutex as a static object. If
not, you need a global mutex, which is used to synchronize the
creation of all of the secondary mutexes, and some tricky way of
initializing it.

In my own code, I generally find it acceptable to require that
threads don't start until after entering main, which means in
practice that the initialization of objects with static
lifetime, at least those which aren't in a dynamically linked
object, has occured. Thus, if you use a singleton, all you have
to do to ensure that it doesn't need a lock is to ensure that at
least one call to the instance function occurs during static
initialization. Something like:

bool dummyForInitial ization = Singleton::inst ance(), tru ;

does the trick, as does:

Singleton* Singleton::ourI nstance = &Singleton::ins tance() ;

A Lock class is presumably implemented as something like:
class Lock
{
private :
PrimitiveLockTy pe PrimitiveLock;
PrimitiveHandle handle;

public:
Lock() {
PrimitiveLock = CreatePrimitive Lock():
handle = StartLocking (PrimitiveLock) ;}

~Lock()
{
StopLocking(han dle);
KillPrimitiveLo ck(PrimitiveLoc k);
}
};

No. An RAII "lock" class is always based on an external mutex
or some other external synchronization primitive. You still
have the problem of creating that external object, of course.

Now if I have two threads there is a chance (albeit a small one) that
I end up creating two PrimitiveLocks

Thus far, I've got around it by making the PrimitiveLock a global
static like the Instance member.

That's normally what you do.

That makes error handling awkward, though if this is failing at such
an early stage then the program's not likely to work anyway.

If creating the lock fails, you have a problem. As you say, it
occurs at such an early stage that the program isn't likely to
work anyway, so you just abort with an error message.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]