Closed
Bug 165639
Opened 23 years ago
Closed 23 years ago
NSSRWLock_UnlockWrite can cause deadlock
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.6
People
(Reporter: julien.pierre, Assigned: wtc)
References
Details
Attachments
(1 file, 1 obsolete file)
|
1.00 KB,
patch
|
Details | Diff | Splinter Review |
When using the re-entrant feature of this lock, deadlocks can occur.
I ran into it with the CRL cache.
The test case is :
acquire the lock for write
acquire the lock for read
unlock the lock for write
unlock the lock for read
Wan-Teh produced a patch for this problem that I will attach.
| Reporter | ||
Updated•23 years ago
|
Priority: -- → P2
Target Milestone: --- → 3.6
| Reporter | ||
Comment 1•23 years ago
|
||
| Assignee | ||
Comment 2•23 years ago
|
||
This patch is equivalent to and shorter than the previous patch
Attachment #97288 -
Attachment is obsolete: true
| Assignee | ||
Comment 3•23 years ago
|
||
The problem was that NSSRWLock_UnlockWrite failed to
wake up waiting readers when the thread releasing
the writer lock still owned the reader lock. Under
this condition, it is fine to let other threads
share the reader lock.
Since this implementation gives preference to waiting
writers, my patch only wakes up waiting readers if
there is no waiting writer.
I have checked the new patch into the tip. Julien,
please verify the fix. I'd also appreciate a code
review by the author of nssrwlk.{h,c}.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 4•23 years ago
|
||
r=nelsonb
You need to log in
before you can comment on or make changes to this bug.
Description
•