Re: WaitForSingleObject() will not deadlock

On Sun, 01 Jul 2007 16:08:59 -0400 Joseph M. Newcomer <newcomer@xxxxxxxxxxxx> wrote:
Two weeks ago, I taught my Systems Programming Course, in which we
use mutexes in the lab on Thursday. I also teach about critical
sections. Last week I taught our Device Driver course, in which I
taught what a mutex is. As well as spin locks, fast mutexes, and
executive resources. I suspect I actually understand what a mutex
is.

Teaching a subject does not qualify you as an expert in it. I have
had some very qualified and very good teachers, but like all of us I
have also had some poor ones. I'm not outright saying you are
unqualified, and I am not implying anything about your teaching skills
(after all, I have no idea), I'm simply saying that your assertion of
qualification or expert knowledge by teaching about it is meaningless.
Furthermore, unless you are talking about a 40 hour course, covering
the topic of synchronization primitives or device drivers in "a week"
is just introductory and again does not demonstrate expert knowledge.

For example, you asked a question which clearly shows you do not
undertand recursive acquisition semantics, one of the fundamental
properties of a mutex. I quote from your post:

if (WaitForSingleObject(mutex, INFINITE) == WAIT_OBJECT_0)
AfxMessageBox("acquired", ID_OK);
if (WaitForSingleObject(mutex, INFINITE) == WAIT_OBJECT_0)
AfxMessageBox("acquired", ID_OK);

You got two message boxes, which is EXACTLY what you should see happen!

Now, if I say :"this would violate the fundamental design of a mutex
to have this deadlock", and it is obvious that it does not deadlock,
it is almost certainly because I understand how mutexes work. You
are insisting that it *should* deadlock, and this shows you do *not*
understand how a mutex works.

Get it straight. I did not insist that it should deadlock, I asked
why it didn't. I didn't find documentation that Windows mutexes were
recursive, so I had to ask. And it's not obvious why it didn't
deadlock; there are 2 possible reasons.

1. The mutex is recursive.
2. WaitForSingleObject() knows that the object has already been
"signalled", and therefore returns success, WITHOUT again
locking the mutex.

As a newcomer to Windows, the WaitForSingleObject() call is confusing
and has unclear semantics to me. In fact, the documentation for
CreateMutex() talks about the mutex being "signaled" and "unsignaled"
as opposed to acquired and released. That was confusing for me.
Hell, I had a hard time figuring out that the '0' at the end of
WAIT_OBJECT_0 was a '0' and not an 'O'.

What you are asking violates the fundamental design of a mutex. I

Fundamental? ha. You mean fundamental to the design of a Windows
mutex.

would suggest that you are the one who doesn't understand them. Of

I agree, I do not understand Windows mutexes. Well, now I understand
them a bit more.

course, had you actually read the documentation on a mutex, you
would have seen the paragraph that says (and I have pasted this from
the MSDN documetation on CreateMutex):
================================
"The thread that owns a mutex can specify the same mutex in repeated
wait function calls without blocking its execution. Typically, you
would not wait repeatedly for the same mutex, but this mechanism
prevents a thread from deadlocking itself while waiting for a mutex
that it already owns. However, to release its ownership, the thread
must call ReleaseMutex once for each time that the mutex satisfied a
wait."
=================================

Thanks, I see that now. Wish I had seen it earlier, would have
answered my question right away.

So you are asking how to create a situation that violates the
fundamental *documented* design of a mutex, and I told you that your
suggestion violates the fundamental design of a mutex; your response
is that I have a limited understanding of what a mutex is, so please
explain exactly what part of a mutex I don't understand?

I will agree that you understand what a Windows mutex is (expert
knowledge even), but in my mind the jury is still out on whether or
not you understand more fundamentally about mutexes in general. Not
saying you don't have a solid grasp, just that your assumptions are
Windows-oriented.

I will submit that it was a mistake on my part to consider any mention
of a mutex in this newsgroup as meaning anything other than a Windows
mutex. Double dumbass on me.

Can you explain and/or point me to documentation on the memory
visiblity semantics of a Windows mutex? I am not trying to draw you
out; this is an honest question.

-frank
.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... And in what way am I wrong about Windows mutexes? ... expectations would violate the *documented* mutex behavior). ... building only experimental systems (my first synchronization system was ...
    (microsoft.public.vc.mfc)
  • Re: msleep() on recursivly locked mutexes
    ... Further the idea that holding a mutex "except for when we sleep" is a ... This is basically when I need to exit mutexes. ... I agree with the other comment that all drivers should be multi-thread ... lock a mutex again. ...
    (freebsd-hackers)
  • Re: msleep() on recursivly locked mutexes
    ... Further the idea that holding a mutex "except for when we sleep" is a ... release it during sleep you probably should invalidate all assumptions ... This is basically when I need to exit mutexes. ... it is not always possible to drop the blocking lock ...
    (freebsd-hackers)
  • Re: Obscure mutex problem
    ... PTHREAD_MUTEX_RECURSIVE to make the mutexes work at all... ... mutex fine, and then thread B would attempt to lock it, but instead ... That pre-NPTL-Linux does not support 'real' multithreading 'but some ...
    (comp.os.linux.development.apps)
  • Re: Thread synchronization
    ... sounds like mutexes might be the best ones to use then. ... I just wanted to use the fastest possible way of synchronization ... > try to perform an interlocked operation on the same variable concurrently, ... > thread releasing a Mutex and a blocked thread coming out its wait on the ...
    (microsoft.public.dotnet.languages.csharp)
Loading