Hi,
1. Your lockWithWriteLock and lockWithReadLock create a lock, which locks on construction and unlocks on destruction, hence when the function returns no lock is held on the mutex.
2. The fact that you put a scope here makes me think that your intention is for the lock to be unlocked at the end of this scope (which it won't, as it is unlocked way before, as per #1).
{ std::cout<<"Program 1: Before first locking -------------------------- 1 v\n"; temp.sharedMutex->lockWithWriteLock(); const unsigned int SLEEP_TIME_IN_SECOND = 60; std::cout<<"Program 1: sleep for "<< SLEEP_TIME_IN_SECOND << "\n"; sleep(SLEEP_TIME_IN_SECOND); std::cout<<"Program 1: Finished sleeping\n"; }
In this case though, you would perform the wait in bold while still holding the lock, and hence preventing the 2nd program from locking it. Once out of the scope you destroy the object right away.
NOTE: both the issue in #1 and #2 lead to your first program possibly deleting the mutex before the 2nd program is done with it. Which leads to the issue you are experiencing.
3. If you need to have the 1st program wait for the 2nd program to be done, then do not use sleeps, use a condition_variable.
Thanks. I didn't know the lock unlocks on destruction. I had taken a cue from a post on StackOverflow: http://stackoverflow.com/questions/12439099/interprocess-reader-writer-lock-... I'm using sleep only for testing purpose. The dilemma still is, how to make the mutex visible to both processes? This thread got rejected by the admin who suggested it could be posted on the users subforum, so kindly reply to my post there to continue the discussion: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-worki... -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-worki... Sent from the Boost - Dev mailing list archive at Nabble.com.