boost::interprocess locks: crashes causing deadlock
Hello, I am currently using boost::inteprocess locks for the windows platform. I've used both the named_recursive_mutex and the interprocess_recursive_mutex. Both implementations use the code below: inline void interprocess_mutex::lock(void) { do{ boost::uint32_t prev_s = detail::atomic_cas32((boost::uint32_t*)&m_s, 1, 0); if (m_s == 1 && prev_s == 0){ break; } // relinquish current timeslice detail::thread_yield(); }while (true); } One issue that I noticed was that if a thread crashes while holding the lock, all other threads stay blocked. If I rerun my process again, my process just hangs at the detail::atomic_cas32() which causes a deadlock. I've tried looking through all the other interprocess locks, and they all seem to filter down to this call. Can someone suggest a locking mechanism where I could lock a resource from all other processes, but if a process crashes that currently owns the lock, other threads will be allowed to acquire the lock? It seems like "file lock" might do what I want, but I wasn't to sure. any suggestions? thx, J
I had the same issue. I am using boost on both windows and linux platform. What I ended up doing i creating a OS layer myself and implemented named mutexes on windows. When a process on windows has a named mutex locked and does not unlock it before it dies the mutex has a state of "Abandoned" and the next process that locked the mutex would have to check this state and if abandoned do the necessary checks and cleanup. ON linux I used file locking between processes and stored a state that each process would have to change before releasing the file lock. If this was not reset the next process that received the files lock would read this value and do the necessary cleanup. File locks on Linux were the only interprocess mechanism that made sense to me, that would release a lock on a process that abandoned it. Hope this helps..... Regards -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jonathon Sent: June-24-10 4:51 PM To: Boost-users@lists.boost.org Subject: [Boost-users] boost::interprocess locks: crashes causing deadlock Hello, I am currently using boost::inteprocess locks for the windows platform. I've used both the named_recursive_mutex and the interprocess_recursive_mutex. Both implementations use the code below: inline void interprocess_mutex::lock(void) { do{ boost::uint32_t prev_s = detail::atomic_cas32((boost::uint32_t*)&m_s, 1, 0); if (m_s == 1 && prev_s == 0){ break; } // relinquish current timeslice detail::thread_yield(); }while (true); } One issue that I noticed was that if a thread crashes while holding the lock, all other threads stay blocked. If I rerun my process again, my process just hangs at the detail::atomic_cas32() which causes a deadlock. I've tried looking through all the other interprocess locks, and they all seem to filter down to this call. Can someone suggest a locking mechanism where I could lock a resource from all other processes, but if a process crashes that currently owns the lock, other threads will be allowed to acquire the lock? It seems like "file lock" might do what I want, but I wasn't to sure. any suggestions? thx, J _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
thanks Carla. I ended up implementing something similar and it seems to work fine. :) On Fri, Jun 25, 2010 at 10:09 AM, Carla Strembicke <Carla.Strembicke@subnet.com> wrote:
I had the same issue.
I am using boost on both windows and linux platform. What I ended up doing i creating a OS layer myself and implemented named mutexes on windows. When a process on windows has a named mutex locked and does not unlock it before it dies the mutex has a state of "Abandoned" and the next process that locked the mutex would have to check this state and if abandoned do the necessary checks and cleanup.
ON linux I used file locking between processes and stored a state that each process would have to change before releasing the file lock. If this was not reset the next process that received the files lock would read this value and do the necessary cleanup. File locks on Linux were the only interprocess mechanism that made sense to me, that would release a lock on a process that abandoned it.
Hope this helps.....
Regards
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jonathon Sent: June-24-10 4:51 PM To: Boost-users@lists.boost.org Subject: [Boost-users] boost::interprocess locks: crashes causing deadlock
Hello,
I am currently using boost::inteprocess locks for the windows platform. I've used both the named_recursive_mutex and the interprocess_recursive_mutex. Both implementations use the code below:
inline void interprocess_mutex::lock(void) { do{ boost::uint32_t prev_s = detail::atomic_cas32((boost::uint32_t*)&m_s, 1, 0);
if (m_s == 1 && prev_s == 0){ break; } // relinquish current timeslice detail::thread_yield(); }while (true); }
One issue that I noticed was that if a thread crashes while holding the lock, all other threads stay blocked. If I rerun my process again, my process just hangs at the detail::atomic_cas32() which causes a deadlock. I've tried looking through all the other interprocess locks, and they all seem to filter down to this call. Can someone suggest a locking mechanism where I could lock a resource from all other processes, but if a process crashes that currently owns the lock, other threads will be allowed to acquire the lock? It seems like "file lock" might do what I want, but I wasn't to sure. any suggestions?
thx, J _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Carla Strembicke -
Jonathon