Is the STL thread safe? Is there a thread-safe version? Or do you need to add you''re own critical sections etc...?

Well, if, as the link on thread safety states, that you need to provide your own synchronization mechanisms (see HMUTEX in Win32 SDK) if any of the threads will write to the container while others will be reading/writing from the same container, you might as well lock the whole thing yourself.

Just write one lock as a class template (if you''re familiar with templates) and use it to wrap the STL container. Methods that "read" from the container will be "const" functions in the container. Methods that actually change the container will be non-const. So, this should make it easy to create a wrapper class with const-overloaded operators.

Something like this:


template &lttypename T>
class exclusive_lock
{
// use very similar code to what smart pointers use, look
// at auto_ptr in MSDN to see what functions you should try
// overloading. overload them for const-ness, i.e.:
inline T* operator ->() { lock(); return &T }
inline const T* operator ->() const { if( is_locked ) lock(); return &T }

exclusive_lock(T& resource) : resource(resource) {}
~exclusive_lock() { unlock(); CloseMutex(...); }

void lock() { OpenMutex(...); is_locked = true; }
void unlock() { if( mutex ) ReleaseMutex(...); is_locked = false; }

private:
T& resource;
HMUTEX mutex;

volatile bool is_locked;
};



Different types of exclusion:

exclusive - only one thread can read or modify the data at a time; no threads can simultaneously read and modify the data;

write exclusive - multiple threads can read the data simultaneously, but only one thread can modify it. No threads may read from the data while it is being modified.

read exclusive - opposite of write exclusive.

Also, I may have some of the function names mixed up but that should be a good idea for a class.

Note that different ports of STL may need different types of exclusion. You should assume only "exclusive" unless the docs for that port say otherwise. "Write exclusive" could probably be better performance-wise. Which method you choose determines how you write the class. Or write a collection of classes.


- null_pointer
Sabre Multimedia

mhkrause: No, actually it synchronises access via the overloaded operators. Unfortunately, my code is missing something else that I should have noticed before. There''s no way to automatically unlock() the resource after the operator has returned. *null pounds head against nearby wall*

You''ll have to use lock()/unlock() manually.



- null_pointer
Sabre Multimedia

thanks

mhkrause: No, I don''t think you understand. Look at this class:


template &lttypename type>
class exclusive_lock
{
public:
exclusive_lock(T& container) : container(container), is_locked(false) {}
~exclusive_lock() { if( is_locked ) unlock(); }

// these are for write access
T& operator * () { lock(); return( container ); unlock(); }
T* operator ->() { lock(); return( &container ); unlock(); }
T& operator = (const T& other) { if( this != &other ) { lock(); container = other.container; unlock(); } }

// these are for read access
const T* operator ->() const { lock(); return( container ); unlock(); }

// manual locking/unlocking
void lock() { /* grab the sync object */; is_locked = true; }
void unlock() { /* release the sync object */; is_locked = false; }

// state info (is volatile desirable here too?)
volatile const bool locked() { return( is_locked ); }

private:
T& container; // no other way to access it, except the operators
volatile bool is_locked; // should be an event object
};



Now that I think of it, perhaps it was the word resource that threw you off with the other code that I posted? The lock''s resource could be a container class or anything else. The only way to access the container would be to use the overloaded operators to call its member functions. Before (and this is the key) the operators return, they lock the mutex or critical section or whatever you use. Then, and only then, can the container''s member function be called.

What type of lock you create still depends on the level of thread safety that your port of STL supports.

And the only actual problem with that class (aside from some stupid bugs) is the code after the return statements in the operators. Yes, I did that on purpose. The operators have to be able to unlock themselves, or my class will simply hang your program indefinitely...hmmm...I think I know how to do it... It could be a performance problem unless it''s optimized very well by the compiler. Return a temp object from the operators with the same operators overloaded, containing a pointer to the sync object, and have its destructor unlock() the lock object. I''m not sure if you can use the same overloaded operator through two classes on the same call... It may actually be better to _not_ overload the operators in the lock class, and instead to make the user get the temp object from a member function and then call the operators on that. That''ll be something to play around with when I''ve got some free time...

The simplest way is always to make the user call lock()/unlock() manually.


- null_pointer
Sabre Multimedia