Re: A simple unit test framework
James Kanze wrote:
On May 7, 10:54 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
James Kanze wrote:
Gianni Mariani wrote:
...
Example ?
Bug #21334 in the std::string implementation in g++.
Not a bug in my opinion. See my other post for a unit test case that
finds the supposed bug in less than 25 milliseconds.
I'll try it. (I'm not 100% sure that there isn't a bug in your
code, however.)
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 ?
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;
}
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.