public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: Ross Johnson <rpj@callisto.canberra.edu.au>
To: pthreads-win32@sources.redhat.com
Subject: Re: issue with recursive mutex
Date: Mon, 24 Jan 2005 14:22:00 -0000	[thread overview]
Message-ID: <1106576535.22573.58.camel@desk.home> (raw)
In-Reply-To: <C72E341DF733CD42A5523C584505E7540C92752B@ad-email1.ad.mc.com>

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 ?
> 


      reply	other threads:[~2005-01-24 14:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-21 15:06 Kubis, Ralf
2005-01-24 14:22 ` Ross Johnson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1106576535.22573.58.camel@desk.home \
    --to=rpj@callisto.canberra.edu.au \
    --cc=pthreads-win32@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).