ConditionVariable use causes thread deadlocks
---------------------------------------------
Key: JRUBY-5093
URL: http://jira.codehaus.org/browse/JRUBY-5093
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.5.2
Reporter: Charles Oliver Nutter
Assignee: Charles Oliver Nutter
Fix For: JRuby 1.5.3, JRuby 1.6
Recently our builds started deadlocking because receiveMail (triggered from
outside the thread) would lock first on the RubyThread instance and then try to
interrupt the thread by acquiring the lock object (currentWaitObject) and
notifying it. Conversely, the locking thread (using the lock object) would try
to acquire the lock object and then acquire the thread lock. As a result, a
deadlock could happen if both tried to do their locking at the same time.
The fix I have found is to move the interrupt call out of receiveMail's
synchronized section, since it doesn't need to be synchronized anyway. This
made the thread sending mail only ever lock on the thread object, which avoids
the deadlock potential.
Along with this fix is Nick Sieger's change for entering one of those wait
states for ThreadLibrary items (like ConditionVariables or Mutexes) and having
a timeout around that call. If the timeout fired between the event poll and the
actual wait, the timeout would get lost. This fix is harder to make perfect,
and Nick fixed it by simply doing another poll immediately before locking. It
does not guarantee the timeout won't get missed, but it makes it less likely.
Timeout itself is flawed.
Fixes coming.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
