mutex

I have two instances running of same Windows Service. They check the health of each other and report if any issue is found. I have a critical job that needs to be performed so I am running it with a fail-over approach, it runs in Master, and if Master is not responding it runs in slave. This job needs to communicate over a specific serial port, I am trying to use Mutex to check for race condition. I dont have access to production, so before deploying I want to make sure my approach is fine. So please suggest if my use of Mutex is fine for the given case. if (iAmRunningInSlave) { HealthClient

Update, 4/10 2012: Fixed by libc patch I have a problem canceling threads in pthread_cond_wait , that use mutexes with the PTHREAD_PRIO_INHERIT attribute set. This only happens on certain platforms though. The following minimal example demonstrates this: (compile with g++ <filename>.cpp -lpthread ) #include <pthread.h> #include <iostream> pthread_mutex_t mutex; pthread_cond_t cond; void clean(void *arg) { std::cout << "clean: Unlocking mutex..." << std::endl; pthread_mutex_unlock((pthread_mutex_t*)arg); std::cout << "clean: Mutex unlocked..." << std::endl; } void *threadFunc(void *arg) { int

I have a class that is accessed from multiple threads. Both of its getter and setter functions are guarded with locks. Are the locks for the getter functions really needed? If so, why? class foo { public: void setCount (int count) { boost::lock_guard<boost::mutex> lg(mutex_); count_ = count; } int count () { boost::lock_guard<boost::mutex> lg(mutex_); // mutex needed? return count_; } private: boost::mutex mutex_; int count_; }; The only way you can get around having the lock is if you can convince yourself that the system will transfer the guarded variable atomicly in all cases. If you can't

Quoting POSIX : The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behavior is required, then that mutex shall be locked by the thread calling pthread_cond_broadcast() or pthread_cond_signal() . "If predictable scheduling behavior is required". This could/would hint that locking the mutex bound to the condition variable right before calling pthread

My app consist of the main-process and two threads, all running concurrently and making use of three fifo-queues: The fifo-q's are Qmain, Q1 and Q2. Internally the queues each use a counter that is incremented when an item is put into the queue, and decremented when an item is 'get'ed from the queue. The processing involve two threads, QMaster, which get from Q1 and Q2, and put into Qmain, Monitor, which put into Q2, and the main process, which get from Qmain and put into Q1. The QMaster-thread loop consecutively checks the counts of Q1 and Q2 and if any items are in the q's, it get's them and

I wonder if it is possible to use Semaphore to implement blocking queue? In the below codes, I use one Semaphore to protect the critical section, and two more Semaphore objects to track the number of empty slots and filled objects. public class BlockingQueue { private List<Object> queue = new LinkedList<Object>(); private int limit; private Semaphore slots; // semaphore for empty slots private Semaphore objs; // semaphore for filled slots private Semaphore mutex; // for the critical section public BlockingQueue(int limit) { this.limit = limit; this.slots = new Semaphore(limit); // initial