Re: A simple unit test framework
On May 8, 2:50 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
James Kanze wrote:
On May 7, 10:54 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
James Kanze wrote:
[...]
Most of the problems in DCL.
They are surprisingly easy to find too.
Really. Consider the following implementation of DCL:
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER ;
pthread_mutex_t mutex2 = PTHREAD_MUTEX_INITIALIZER ;
Singleton* theOneAndOnly = NULL ;
static Singleton*
Singleton::instance()
{
if ( theOneAndOnly == NULL ) {
Locker lock( mutex1 ) ;
if ( theOneAndOnly == NULL ) {
Singleton* tmp ;
{
Locker lock2( mutex2 ) ;
tmp = new Singleton ;
}
theOneAndOnly = tmp ;
}
}
return theOneAndOnly ;
}
It doesn't work, but can you write a test which will reveal the
error? (For starters, you certainly cannot on most Intel 32
bits processors, because they do guarantee that it works, even
if it violates Posix, and fails in practice on some other
architectures.)
What is that mutex2 doinf other than an attempt to make mods visible ?
It's making the modifications in the constructor of Singleton
visible before allowing the modification of theOneAndOnly.
Without it, the compler or the write scheduler in the CPU can
reorder the writes, so that the write of the non-null value to
Singleton precedes the writes in the constructor of the
Singleton.
Obviously, you don't need a mutex. Introducing some platform
specific membar or fence instructions can achieve the same ends.
But I felt that using Posix was going far enough; I didn't want
to throw in inline ASM.
GCC supports it like:
static Singleton* Singleton::instance()
{
static Singleton* s_x = new Singleton;
return s_x;
}
or even:
static Singleton* Singleton::instance()
{
static Singleton s_x;
return & s_x;
}
On some platforms. The generated code doesn't work on a Sparc,
or at least, it doesn't meet the guarantees it is claimed to.
In 32 bit mode, on a Sparc, it can even result in an endless
loop; I consistently use the option to turn it off. (In 64 bit
mode, it's missing a critical membar. Which means that on most
machines, it will work anyway, because most Sparc processors
don't use the fully relaxed memory model. Which is a real trap,
because obviously, until you do use the relaxed memory model,
the code works. A hardware upgrade, and it starts crashing.
Only rarely, and of course, nothing that you can reproduce.)
OK - DCL on singletons, I'd implement it using thread local data. Yes,
a hard one for memory systems with visibility issues. This is one of
the cases where you have to re-start the whole executable and introduce
randomization on start up and you need to determine how the errors are
found. i.e. two threads calling Singleton::instance() returning
different values.
I must admit, I have not had much experience on recent archs that need
acquire and release semantics.
They do make life rather difficult. Not just for testing.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34