Hi,

I have 4 application sharing a piece of memory, protected by a named Mutex.

If one application crashes while having aqquired the Mutex, then it should 
release it right ? and if 4 applications has aqquired a handle for the named 
Mutex, then all 4 has to quit before the Mutex is removed from the system 
right ?

Doesnt this mean that a named Mutex never can go into a deadlock ? the only 
problem there could be with a mutex would be if for some reason the code 
(programatically) forgets to release the mutex again right ?

"Niel Darren" <nods@pszzxasm.co.uk> wrote in
news:461e4eee$0$192$edfadb0f@dread11.news.tele.dk: 

> Hi,
> 
> I have 4 application sharing a piece of memory, protected by a
> named Mutex. 
> 
> If one application crashes while having aqquired the Mutex, then
> it should release it right ?

Are you asking whether the application should be coded to do so, or 
are you asking whether Win32 will enforce this?

I do not believe that Win32 will release a Mutex if the application 
holding it terminates abnormally. It is up to the application to 
handle that possibility (say, with structured exception handlers) 
if that is the right thing to do.

Whether this would be the right thing to do is hard to say without 
knowing more about the application. Consider that the application 
may have crashed while it was updating the information in the 
shared memory, leaving it in an inconsistent state. It could be 
dangerous to simply release the Mutex and let another application 
access the corrupt information.

On the other hand, if the application was only reading the 
information, then it _might_ be safe to unlock the Mutex.

>                              and if 4 applications has aqquired
> a handle for the named Mutex, then all 4 has to quit before the
> Mutex is removed from the system right ?

All handles would have to be closed, which does not necessarily 
require the applications to exit.

> 
> Doesnt this mean that a named Mutex never can go into a deadlock
> ? the only problem there could be with a mutex would be if for
> some reason the code (programatically) forgets to release the
> mutex again right ? 
> 

Strictly speaking, you cannot have a deadlock if there is only
one resource being shared. But if the holder of the Mutex fails
to release it (for whatever reason,) then the other applications
will be prevented from locking it and may be unable to make any
progress.

MV

-- 
I do not want replies; please follow-up to the group.

Niel Darren wrote:

> I have 4 application sharing a piece of memory, protected by a named Mutex.
> 
> If one application crashes while having aqquired the Mutex, then it should 
> release it right ?

It will, but other applications can detect the abandoned mutex. For
example, in .NET 2.0, acquiring a named mutex that was previously
abandoned will cause an AbandonedMutexException to be thrown. At the
Win32 API level, WAIT_ABANDONED is returned from a wait function
acquiring the mutex. It's documented in the Platform SDK:

"If a thread terminates without releasing its ownership of a mutex
object, the mutex object is considered to be abandoned. A waiting thread
can acquire ownership of an abandoned mutex object, but the wait
function will return WAIT_ABANDONED to indicate that the mutex object is
abandoned. An abandoned mutex object indicates that an error has
occurred and that any shared resource being protected by the mutex
object is in an undefined state. If the thread proceeds as though the
mutex object had not been abandoned, it is no longer considered
abandoned after the thread releases its ownership. This restores normal
behavior if a handle to the mutex object is subsequently specified in a
wait function."

State protected by an abandoned mutex may be corrupted. It's dangerous
to trust it unless you've designed for that.

> Doesnt this mean that a named Mutex never can go into a deadlock ? the only 
> problem there could be with a mutex would be if for some reason the code 
> (programatically) forgets to release the mutex again right ?

Not at all. Mutexes A and B, processes 1 and 2. 1 gets A, 2 gets B, 1
blocks trying to get B, 2 blocks trying to get A, deadlock with named
mutexes.

Or did I not understand your question?

-- Barry

-- 
http://barrkel.blogspot.com/

Barry Kelly <barry.j.kelly@gmail.com> wrote in
news:qlts13lm2k8tc0214mgfmg0d86vecq2qsb@4ax.com: 

> thrown. At the Win32 API level, WAIT_ABANDONED is returned from
> a wait function acquiring the mutex. It's documented in the
> Platform SDK: 

I stand corrected. Must be old age catching up
with me :-(

MV

-- 
I do not want replies; please follow-up to the group.

On Apr 12, 8:24 am, "Niel Darren" <n...@pszzxasm.co.uk> wrote:

> If one application crashes while having aqquired the Mutex, then it should
> release it right ?

Oh god no! That would be a disaster!

You acquire a mutex so that you can modify the information the mutex
protects. You release the mutex as soon as the information is in a
sane and consistent state. If an application crashes while it holds a
mutex, the information protected by the mutex may be in an insane and
inconsistent state (say with an object half-added toa  double-linked
list). The next program to come around should not be permitted to
acquire the mutex as if nothing was wrong!

DS

"Niel Darren" <nods@pszzxasm.co.uk> wrote in message 
news:461e4eee$0$192$edfadb0f@dread11.news.tele.dk...
> Hi,
>
> I have 4 application sharing a piece of memory, protected by a named 
> Mutex.
>
> If one application crashes while having aqquired the Mutex, then it should 
> release it right ?

Windows mutexs will go into a so-called abandoned state when a process 
screws up and dies for whatever reason while its holding them.


Read this whole thread:

http://groups.google.com/group/comp.programming.threads/msg/94f2a233bd65bf8a

....

Hi Barry (and the rest of you).

Yes you understood me correctly, and have checked up on the wait_abandoned 
state, and it really suits the design ok.

I can understand the issues with the possibility of corrupt data if a crash 
would happen from one application, but its a tolerable situation, the most 
important thing is that it wouldnt case some deadlock because an application 
has crashed, and cause all the other applications to crash.

The AB,12 situation thats taken care of, due to the fact there is only one 
area protected by a mutex, but if there was more, then i would have to do 
some synchronization.

That makes me think of another thing, how on earth would you do this across 
processes ? a sempahore-based solution would dangerous because that could 
cause havoc in the situation where one application might crash since it 
wouldnt be released automatically as with mutexes right ?

But thanks alot all for your input here, it really helps alot.

"Niel Darren" <nods@pszzxasm.co.uk> wrote in
news:461f6056$0$185$edfadb0f@dread11.news.tele.dk: 

> That makes me think of another thing, how on earth would you do
> this across processes ? a sempahore-based solution would
> dangerous because that could cause havoc in the situation where
> one application might crash since it wouldnt be released
> automatically as with mutexes right ? 

I don't understand the question. Haven't we been
talking about using a Mutex across processes all along?

A Mutex can be named, so any number of processes
can use the same Mutex to synchronize with each other.

MV

-- 
I do not want replies; please follow-up to the group.