Re: WaitForSingleObject() will not deadlock

No, trylock and its equivalents only say that the object is locked. It does not guarantee
that you can lock an object and examine it, so it won't do the job of walking a circular
structure when there are potentially concurrent walkers.
joe

On Sun, 01 Jul 2007 23:47:50 -0700, Frank Cusack <fcusack@xxxxxxxxxxx> wrote:

On Mon, 02 Jul 2007 01:37:50 -0400 Joseph M. Newcomer <newcomer@xxxxxxxxxxxx> wrote:
I was not aware that anyone would design a non-recursive mutex,
since this has been an integral part of lock design for at least 20
years, if not longer.

I haven't known our good friend the mutex for so long, but I would
hazard a guess that posix mutexes have ALWAYS had recursion as
an option. Because posix has a non-recursive mutex (by default)
doesn't mean it hasn't also always had a recursive mutex.

I was using recursive-acquisition locks in the late 1980s and they
were a well-known technology at the time I was using them. A
non-recursive mutex is not usable for doing things like traversing
circular lists trying to detect circularity, for example.

Sure it is, use trylock() instead of lock().

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

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... How do two independent iterators solve the been-there-done-that problem? ... With recursive mutexes, you should not NEED to know the lock count, and therefore the lock ... Your claim was that a non-recursive mutex cannot solve this problem. ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... from the nature of circular list detection. ... Your claim was that a non-recursive mutex cannot solve this problem. ... With recursive mutexes, if you have ... no way to determine the lock count, ...
    (microsoft.public.vc.mfc)
Loading