Re: [Boost-users] boost::interprocess locks: crashes causing deadlock

Subject: Re: [Boost-users] boost::interprocess locks: crashes causing deadlock
From: Carla Strembicke (Carla.Strembicke_at_[hidden])
Date: 2010-06-25 13:09:23

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_at_[hidden] [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Jonathon
Sent: June-24-10 4:51 PM
To: Boost-users_at_[hidden]
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_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users