Re: Emulating PTHREAD_MUTEX_RECURSIVE - recursive mutex implementation...

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. :)


.

Relevant Pages
Loading