[Boost-users] Boost interprocess named mutexes

[Mike Spertus]

I am seeing the following problems with Boost interprocess named
mutexes on Windows.

1. As mentioned in my other threads, interprocess mutexes do not provide
mutual exclusion between processes run by different users. The reason
for this is the shared memory mappings backing the mutexes are placed in
different directories.

2. If a process crashes while holding a mutex, no other process can
subsequently acquire the mutex.

3. Although the documentation says that mutexes have process
persistence, they appear to have filesystem persistence. This means that
is a process or system crashes while the mutex is held, the mutex is
permanently unavailable (without deleting it).

Are these accurate statements? If so, could these be addressed by having
Boost::interprocess use Win32 named mutexes (which I understand to have
none of these defects) like it uses pthread mutexes on Linux?

Thanks,

Mike

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Ion Gaztañaga]

Mike Spertus escribió:

> I am seeing the following problems with Boost interprocess named
> mutexes on Windows.

> 3. Although the documentation says that mutexes have process

> persistence, they appear to have filesystem persistence. This means that
> is a process or system crashes while the mutex is held, the mutex is
> permanently unavailable (without deleting it).

The documentation says kernel or filesystem persistence for "named mutex":
http://www.boost.org/doc/libs/1_39_0/doc/html/interprocess/some_basic_explanations.html#interprocess.some_basic_explanations.persistence

Best,

Ion

[Mike Spertus]

Ion Gaztanaga wrote:
> Mike Spertus escribió:
> > I am seeing the following problems with Boost interprocess named
> > mutexes on Windows.
>
> > 3. Although the documentation says that mutexes have process
> > persistence, they appear to have filesystem persistence. This means that
> > is a process or system crashes while the mutex is held, the mutex is
> > permanently unavailable (without deleting it).
>
> The documentation says kernel or filesystem persistence for "named mutex":
> http://www.boost.org/doc/libs/1_39_0/doc/html/interprocess/some_basic_explanations.html#interprocess.some_basic_explanations.persistence
>
>

Hi Ion,
Sorry, I misread that doc page. You are of course correct. What do you
think of my suggestion to use a Windows mutex to back a boost
interprocess named mutex? Since "abandoned Windows mutexes" are
automatically released by Windows, we see substantially fewer hangs when
we use Windows mutexes.

Thanks,

Mike

[Ion Gaztañaga]

Mike Spertus escribió:

> Sorry, I misread that doc page. You are of course correct. What do you
> think of my suggestion to use a Windows mutex to back a boost
> interprocess named mutex? Since "abandoned Windows mutexes" are
> automatically released by Windows, we see substantially fewer hangs when
> we use Windows mutexes.

Windows named mutexes have reference-counted semantics, so they
disappear when the last attached process dies, so they are not ompatible
with POSIX lifetime semantics.