issue with recursive mutex

issue with recursive mutex

[Kubis, Ralf]

Hello,

I apologize if that issue came already up in this list but I can't see
it in the archive.
Got snapshot 2005-01-03 and ran into a deadlock with recursive mutexes.

Looking at the code in pthread_mutex_lock.c and pthread_mutex_unlock.c I
see the following problem.


mutex m;


Thread 0 
--------
m.lock()

Thread 1
--------
m.lock() <- is waiting now

Thread 0
--------
m.lock() <- refcount is now 2 and mx->lock_idx is now 1 !!!!

Thread 0
--------

m.unlock() <- refcount is now 1
m.unlock() <- refcount is now 0 and mx->lock_idx is now 0. 
              no event was send because mx->lock_idx was not less than 0


Thread 1
--------
still locked  :(


After a small modification in pthread_mutex_lock.c, listed below, the
mutex behaved like expected but
indeed this has the cost of sending unnecessary events.
Where does your implementation come from ?

-- 
Best regards,
 Ralf Kubis


ps:

as a first hack I've changed pthread_mutex_lock.c from

  if (mx->kind == PTHREAD_MUTEX_RECURSIVE)
  {
      mx->recursive_count++;
  }

to

  if (mx->kind == PTHREAD_MUTEX_RECURSIVE)
  {
      mx->recursive_count++;
	mx->lock_idx = -1; // assume that there are waiters
  }

Re: issue with recursive mutex

[Ross Johnson]

On Fri, 2005-01-21 at 10:06 -0500, Kubis, Ralf wrote: 
> Hello,
> 
> I apologize if that issue came already up in this list but I can't see
> it in the archive.
> Got snapshot 2005-01-03 and ran into a deadlock with recursive mutexes.
> 

Hi Ralf,

Snapshots since 2004-11-03 have been trying a new mutex implementation.
So the issue is new, and the error is in the way that I've adapted
Alexander Terekhov's new implementation for 'normal' mutexes (see links
below) to the pre-existing code for recursive mutexes.

Re where does the [current] implementation come from - please see the
following list messages:

http://sources.redhat.com/ml/pthreads-win32/2003/msg00108.html

http://sources.redhat.com/ml/pthreads-win32/2004/msg00119.html

Although it's a little out of date w.r.t. the current implementation,
there's more information on the reasons behind using a new
implementation here:
http://sources.redhat.com/ml/pthreads-win32/2004/msg00118.html

Thanks for isolating the problem and providing the patch. I'll modify it
a little so it won't result in additional unnecessary events. I should
be able to get a new snapshot out tuesday including this and other
recently reported problems fixed.

Thanks, and apologies for the inconvenience.

Ross

> Looking at the code in pthread_mutex_lock.c and pthread_mutex_unlock.c I
> see the following problem.
> 
> 
> mutex m;
> 
> 
> Thread 0 
> --------
> m.lock()
> 
> Thread 1
> --------
> m.lock() <- is waiting now
> 
> Thread 0
> --------
> m.lock() <- refcount is now 2 and mx->lock_idx is now 1 !!!!
> 
> Thread 0
> --------
> 
> m.unlock() <- refcount is now 1
> m.unlock() <- refcount is now 0 and mx->lock_idx is now 0. 
>               no event was send because mx->lock_idx was not less than 0
> 
> 
> Thread 1
> --------
> still locked  :(
> 
> 
> After a small modification in pthread_mutex_lock.c, listed below, the
> mutex behaved like expected but
> indeed this has the cost of sending unnecessary events.
> Where does your implementation come from ?
>