Mutex interchangeable implementations can be implemented (regardless of the flow implementation)

Question

Do all mutex implementations ultimately cause the same basic system / hardware calls - which means they can be interchangeable?

In particular, if I use __gnu_parallel algorithms (which use openmp ), and I want the classes that they called threadafe to use boost::mutex to block? or should I write my own mutex such as described here

 //An openmp mutex. Can this be replaced with boost::mutex? class Mutex { public: Mutex() { omp_init_lock(&_mutex); } ~Mutex() { omp_destroy_lock(&_mutex); } void lock() { omp_set_lock(&_mutex); } void unlock() { omp_unset_lock(&_mutex); } private: omp_lock_t _mutex; }; 

Edit, the link above to mutex openmp seems to be broken, for anyone interested, the lock that goes with this mutez is in these lines

 class Lock { public: Lock(Mutex& mutex) : m_mutex(mutex), m_release(false) { m_mutex.lock(); } ~Lock() { if (!m_release) m_mutex.unlock(); } bool operator() const { return !m_release; } void release() { if (!m_release) { m_release = true; m_mutex.unlock(); } } private: Mutex& m_mutex; bool m_release; }; 

Answer 1

You cannot mix synchronization mechanisms. For instance. The current implementation of mutex pthreads is based on futex and differs from previous implementations of pthreads (see man 7 pthreads ). If you create your own level of abstraction, you should use it. Should you consider what you need - inter-thread or interprocess synchronization? If you need to collaborate with code that uses boost :: mutex, you should use boost :: mutex instead of open mp. In addition, IMHO it is rather strange to use the functions of open mp-libraries to implement the mutex.

Answer 2

This link gives a useful discussion:

http://groups.google.com/group/comp.programming.threads/browse_thread/thread/67e7b9b9d6a4b7df?pli=1

To paraphrase (at least on Linux) Boost :: Thread and OpenMP both the interface to pthread and in principle should be able to be mixed (as Anders +1 claims), but mixing streaming technologies in this way is usually bad idea (as Andy says, +1).

Answer 3

The part that requires compatibility is pausing the stream, reconfiguring, and switching contexts. As long as the threads are real threads planned by the operating system, you should use any mutex implementation that relies on some kind of kernel primitive to pause and resume the waiting thread.