Re: Emulating PTHREAD_MUTEX_RECURSIVE - recursive mutex implementation...

On Mar 12, 3:13 am, "Bin Chen" <binary.c...@xxxxxxxxx> wrote:
On Mar 11, 11:52 pm, "Mirek Fidler" <c...@xxxxxxxxxx> wrote:



On Mar 11, 1:54 pm, "peter koch" <peter.koch.lar...@xxxxxxxxx> wrote:

On 11 Mar., 08:38, "Mirek Fidler" <c...@xxxxxxxxxx> wrote:

On Mar 11, 7:54 am, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:

http://groups.google.com/group/comp.programming.threads/msg/011401eb8...

sketch of a working solution...

Seems overly complicated and slow to me. Can you point out where are
the problems with mine solution first?

However, recursive is not really required
for anything... Think about it!

Yes, in theory, you are right.

However, I have just spent 4 days hunting down a bug which in the end
turned out to be non-recursive mutex deadlock - and that was not the
first time.

I think my solution comes practically for free, no expensive
operations are provided, so for my own sanity, I rather plan to use
recursive mutexes in the future.

Mirek

It might come from free, but it does encourage bad programming
practice. Always use non-recursive mutexes only. My "wrapper" over the
lightweight Windows mutex (CRITICALSECTION) checks that the mutex is
not locked recursively (when compiling in debug mode), and I believe
that this forces the users (primarily myself!) to implement cleaner
multithreading code.

Well, what you suggest is exactly what I was using up to this point -
altered windows critical section to disallow recursive locking. Still,
some errors obviously were left undetected.

As for "bad programming practice", I would not be so sure. I have
found non-recursive mutex to lead to more complex code in general.
Additional complexity is always a possible source of errors.

Although it is a digression, I want to know the extreme cases that you
must use recursive mutex to fulfill your design, I think many guys on
this groups also want to know. :)

"must" is not the same thing as "makes code simpler and less error
prone".

Of course, you can write all the code without recursive mutexes.

As for the case that took me 4 days of bug hunting:

In my memory allocator, there is a possibility to get memory profile
(memory allocation histogram). There is also possibility to record
"peak" memory profile - this gets recorded when allocator requires
more memory from the system. This option is normally off and gets
activated only occasianally. Even when activated, it not always
happens (because no more memory is required from system).

Now creating memory profile requires serialization, as well as
allocation itself (in case when more memory is required from system).
Which is deadlock.

Obviously, solution is to create locked and unlocked version of
getmemoryprofile. I have done this many times before. But in practice,
this can more than double number of functions dealing with serialized
data - and you still are prone to make a bug. You have to keep track
of the whole call tree of any serialized function and make sure that
only unlocked functions are called.

Mirek

.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... Whatever memory values a thread can see when it unlocks a mutex (leaves ... situation of this nature on any closely-coupled MIMD architecture, ... can exist in a distributed MIMD architecture, but in that case, the mutice have to keep ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... data written after the mutex is ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... and after the clause, "However, if you were to uncomment the line that sets ... data written after the mutex is ... No, you have to lock the same mutex, and reflects that. ...
    (microsoft.public.vc.mfc)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... and after the clause, "However, if you were to uncomment the line that sets ... data written after the mutex is ... No, you have to lock the same mutex, and reflects that. ...
    (microsoft.public.vc.mfc)
  • Re: Emulating PTHREAD_MUTEX_RECURSIVE - recursive mutex implementation...
    ... the problems with mine solution first? ... turned out to be non-recursive mutex deadlock - and that was not the ... found non-recursive mutex to lead to more complex code in general. ...
    (comp.programming.threads)