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

Subject: Re: [Boost-users] boost::interprocess locks: crashes causing deadlock
From: Jonathon (thejunkjon_at_[hidden])
Date: 2010-06-25 15:28:24

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_at_[hidden]> 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_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
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>