Re: WaitForSingleObject() will not deadlock

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.

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.

What you are asking violates the fundamental design of a mutex. I would suggest that you
are the one who doesn't understand them. Of 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."
=================================
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?
joe

On Sun, 01 Jul 2007 01:40:28 -0700, Frank Cusack <fcusack@xxxxxxxxxxx> wrote:

On Sat, 30 Jun 2007 23:05:58 -0400 Joseph M. Newcomer <newcomer@xxxxxxxxxxxx> wrote:
You can't, it is impossible; it violates the fundamental design of a mutex!!!!

You obviously are limited in your understanding of what a mutex is.

-frank
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • [patch] lockdep: annotate vfs_rmdir for filesystems that take i_mutex in delete_inode
    ... That's notabug and lockdep will need to be taught about it. ... This is another 3 level locking ordering: ... do_rmdir takes the mutex of the parent directory ... vfs_rmdir takes the mutex of the victim ...
    (Linux-Kernel)
  • 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)