libgcj/1216: wait/notify doesn't work if monitor is locked recursivly

libgcj/1216: wait/notify doesn't work if monitor is locked recursivly

[bryce]

>Number:         1216
>Category:       libgcj
>Synopsis:       wait/notify doesn't work if monitor is locked recursivly
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    bryce
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:17:47 PST 2000
>Closed-Date:    Mon Mar 27 18:35:24 PST 2000
>Last-Modified:  Mon Mar 27 18:40:02 PST 2000
>Originator:     Bryce McKinlay
>Release:        unknown-1.0
>Organization:
>Environment:
RedHat 6.1 w/ glibc 2.1.3
>Description:
We use recursive mutexes on pthreads implementations that 
support them. On linux, at least, pthread_cond_wait()
just calls pthread_mutex_unlock(), which of course doesn't 
"fully" unlock a recursive mutex - only decrements its 
lock count! 

This means that ownership of the monitor is not 
relinquished on wait(), resulting in a deadlock if the 
thread has aquired the monitor more than once. 

>How-To-Repeat:
Run the attached test case.
>Fix:
Never use native recursive mutexes, instead implementing
the recursion ourselves. This would clean up the code in
posix_threads.h considerably, fix the Solaris 7 bug (PR 110), 
and IMO would have a negligable impact on performance. 
>Release-Note:

>Audit-Trail:

Formerly PR libgcj/171

Responsible-Changed-From-To: tromey->bryce
Responsible-Changed-By: bryce
Responsible-Changed-When: Thu Mar 23 06:08:42 2000
Responsible-Changed-Why:
    I fixed it.
State-Changed-From-To: open->feedback
State-Changed-By: bryce
State-Changed-When: Thu Mar 23 06:08:42 2000
State-Changed-Why:
    Patch submitted:
    http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00248.html

From: bryce@albatross.co.nz
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/171
Date: 23 Mar 2000 14:08:42 -0000

 Synopsis: wait/notify doesn't work if monitor is locked recursivly
 
 Responsible-Changed-From-To: tromey->bryce
 Responsible-Changed-By: bryce
 Responsible-Changed-When: Thu Mar 23 06:08:42 2000
 Responsible-Changed-Why:
     I fixed it.
 State-Changed-From-To: open->feedback
 State-Changed-By: bryce
 State-Changed-When: Thu Mar 23 06:08:42 2000
 State-Changed-Why:
     Patch submitted:
     http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00248.html
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=171&database=java
State-Changed-From-To: feedback->closed
State-Changed-By: bryce
State-Changed-When: Mon Mar 27 18:35:24 2000
State-Changed-Why:
    Patch has been committed to cvs.

From: bryce@albatross.co.nz
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: libgcj/171
Date: 28 Mar 2000 02:35:25 -0000

 Synopsis: wait/notify doesn't work if monitor is locked recursivly
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: bryce
 State-Changed-When: Mon Mar 27 18:35:24 2000
 State-Changed-Why:
     Patch has been committed to cvs.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=171&database=java
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="RecursiveLock.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="RecursiveLock.java"

cHVibGljIGNsYXNzIFJlY3Vyc2l2ZUxvY2sgZXh0ZW5kcyBUaHJlYWQKewogIHB1YmxpYyBzdGF0
aWMgdm9pZCBtYWluKFN0cmluZyBhcmdzW10pIHRocm93cyBJbnRlcnJ1cHRlZEV4Y2VwdGlvbgog
IHsKICAgIFJlY3Vyc2l2ZUxvY2sgcmwgPSBuZXcgUmVjdXJzaXZlTG9jaygpOwogICAgcmwuc3Rh
cnQoKTsKICAgIC8vIEdpdmUgdGhlIGNoaWxkIHRocmVhZCB0aW1lIHRvIHN0YXJ0IHVwLgogICAg
VGhyZWFkLnNsZWVwKDEwMDApOwogICAgc3luY2hyb25pemVkIChybCkKICAgIHsKICAgICAgcmwu
bm90aWZ5KCk7CiAgICB9CiAgfQogIAogIHB1YmxpYyBzeW5jaHJvbml6ZWQgdm9pZCBydW4oKQog
IHsKICAgIC8vIE5vdGU6IHR3byBsZXZlbHMgb2Ygc3luY2hyb25pemF0aW9uLi4uCiAgICBzeW5j
aHJvbml6ZWQgKHRoaXMpCiAgICB7CiAgICAgIHRyeQogICAgICB7CglTeXN0ZW0ub3V0LnByaW50
bG4oIndhaXQoKS4uLiIpOwoJd2FpdCgpOwoJU3lzdGVtLm91dC5wcmludGxuKCJvayIpOwogICAg
ICB9CiAgICAgIGNhdGNoIChJbnRlcnJ1cHRlZEV4Y2VwdGlvbiB4KQogICAgICB7CglTeXN0ZW0u
b3V0LnByaW50bG4oeCk7CiAgICAgIH0KICAgIH0KICB9ICAKfQo=