Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#167 class ClassLevelLockable in Threads break at Thread.h 574

closed-wont-fix
None
5
2011-10-07
2009-10-27
Albert xu
No

Inside the ClassLevelLockable Class, the Initializer member has a bug during initialization.

struct Initializer
{

/// This function provides a Scott-Meyers type of Singleton as the initializer
/// for the shared mutex.
static Initializer & GetIt( void )
{
static Initializer initializer_;
return initializer_;
}

inline bool IsInit( void ) { return init_; }
inline MutexPolicy & GetMutex( void ) { return mtx_; }

private:
bool init_;
MutexPolicy mtx_;

Initializer() : init_(false), mtx_()
{
init_ = true;
}

~Initializer()
{
assert(init_);
}

Initializer( const Initializer & );
Initializer & operator = ( const Initializer & );
};

After the Initialzer constructor, the code breaks on the assert( initialzer.IsInit() );
This bug happens when two threads call the constructor of ClassLevelLockable::Lock() at the same time.

Discussion

  • Sorry, but I don't think this problem can be fixed by a change to Loki. Loki can control multiple thread access to a mutex that already exists, but can't control multiple threads trying to construct or destruct a mutex concurrently.

    That's a problem which must be solved at a higher level within the program. The program needs to explicitly call functions which cause the initialization before other threads can access the object. (Perhaps a thread can call Host::Initializer::GetIt() to force initialization before other threads call Lock.)

    If you know of a way Loki can protect a mutex from this problem, please let me know.

     
    • assigned_to: nobody --> rich_sposato
    • status: open --> closed-wont-fix