Modifying boost :: Lockable using a semaphore rather than a mutex (formerly called: unlocking a mutex from another thread)

I am using the C ++ boost :: thread library, which in my case means I am using pthreads. Officially, the mutex must be unlocked from the same thread that is blocking it, and I want the effect to be able to be committed on one thread and then unlocked on another. There are many ways to do this. One possibility would be to write a new mutex class that allows this behavior.

For instance:

class inter_thread_mutex{
  bool locked;
  boost::mutex mx;
  boost::condition_variable cv;
public:
  void lock(){
    boost::unique_lock<boost::mutex> lck(mx);
    while(locked) cv.wait(lck);
    locked=true;
  }

  void unlock(){
    {
      boost::lock_guard<boost::mutex> lck(mx);
      if(!locked) error();
      locked=false;
    }
    cv.notify_one();
  }
// bool try_lock(); void error(); etc.
}

      

        
        
        
      

    

I should point out that the above code does not guarantee FIFO access, because if one thread calls lock () and another calls unlock (), that first thread can acquire the lock before other threads that are waiting. (Think about it, the boost :: thread documentation doesn't show any explicit scheduling guarantees for both mutexes or condition variables.) But let's just ignore this (and any other errors) for now.

My question is, if I decide to go this route, would I be able to use such a mutex as a model for the Lockable concept. For example, something goes wrong if I use boost::unique_lock< inter_thread_mutex >

RAII for access and then pass that lock to boost::condition_variable_any.wait()

, etc.

On the one hand, I don't understand why not. On the other hand, “I don’t understand why not” is usually a very bad way to determine if something will work.

The reason I am asking is that if it turns out that I have to write wrapper classes for locks and RAII state variables and something else, then I would rather find another way to achieve the same effect.

EDIT: The behavior I want is basically as follows. I have an object and it needs to be blocked whenever it changes. I want to lock an object from one thread and do some work on it. Then I want the object to be locked while I tell another worker thread to shut down. So the first thread can continue and do something else while the worker thread ends. When the worker thread exits, it unlocks the mutex.

And I want the transition to seem indifferent, so no one can lock the mutex in between when thread 1 starts up and thread 2 ends it.

Something like inter_thread_mutex looks like this will work and it will also allow the program to interact with it as if it were a normal mutex. So this seems like a clean solution. If there is a better solution, I would be glad to hear that as well.

EDIT AGAIN: The reason I need locks is because there are multiple main threads, and the locks are there so that they cannot access shared objects at the same time in invalid ways. So the code is already using loop level sequencing at the main thread level at the loop level. Also, there were no worker threads in the original implementation, and the mutexes were regular kosher mutexes.

Inter_thread_thingy appeared as an optimization primarily to improve response times. In many cases it was sufficient to ensure that the "first part" of operation A occurs before the "first part" of operation B. As a dumb example, let's say I punch through object 1 and give it a black eye. Then I tell object 1 to change its internal structure to reflect any tissue damage. I do not want to wait for tissue damage before I move on to hitting object 2. However, I want tissue damage to occur as part of the same operation; for example in between, I don't want any other thread to reconfigure the object in such a way that tissue damage would result in an invalid operation. (yes, this example is imperfect in many ways and I am not working on the game)

So, we made a change to the model where ownership of an object can be passed to a worker thread to complete an operation, and that actually works really well; each main thread can receive a lot more operations because there is no need to wait for all of them to complete. And since the sequence of events at the main thread level is still loop-based, it is easy to write the high-level operations of the master thread, since they can be based on the assumption that the operation has completed (more precisely, the critical "first part" that the sequence logic depends on) when the corresponding function call returns.

Finally, I thought it would be nice to use inter_thread mutex / semaphore thingies using RAII with boost locks to encapsulate the necessary synchronization needed for this to work.