5

I have the following boost::interprocess::message_queue related question.

As intended I plan to share a message queue between >= 2 processes. Obviously one of them may crash while inside the message queue. As result it will hold the internal locks, making the queue inaccessible for other processes. How can this be solved? There does not seem to be a way to unlock the internal mutex used.

Yordan Pavlov
  • 1,303
  • 2
  • 13
  • 26

1 Answers1

0

We can use the method of predicate wait in other processes(1 min or greater based on requirement) then if that satisfies then forcefully unlock the queue by the second process then again lock for pushing and unlock after reading?

for more details see the below ref.

http://en.cppreference.com/w/cpp/thread/condition_variable/wait

Edit:

We can't unlock the internal locks, I thought that you are manually locking the queue using

scoped_lock lock(mutex);

So you can unlock using the predicate_wait when the time finished then unlock it. from other process.

smali
  • 4,687
  • 7
  • 38
  • 60
  • Hi Ali, how do we "forcefully unlock the queue by the second process"? – Yordan Pavlov Jul 10 '14 at 14:22
  • Hi, Forcefully means just unlock the queue manually after the condition satisfies. – smali Jul 10 '14 at 17:32
  • Please specify which method to use to "unlock the queue manually" http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/message_queue_t.html – Yordan Pavlov Jul 11 '14 at 10:36
  • Sorry See my edits, but you can use you'r own locks to avoid this situation. – smali Jul 11 '14 at 12:03
  • The problem is that message_queue is internally synchronized. I do not think I can access in thread unsafe way and synchronize it 'outside' with my own locks. There is always the possibility for my other thread to crash while the internal locks is acquired. – Yordan Pavlov Jul 16 '14 at 07:40
  • But I am using the same what i have told you I have implemented a persistent Queue and using my own Synchronization locks. And I am using Condition variable to notify the other thread that data is ready to, avoid continuously polling. – smali Jul 16 '14 at 07:45