JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-6373

ThreadError: Mutex is not owned by calling thread, when interrupting thread using a Ruby Mutex

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.6.5
    • Fix Version/s: JRuby 1.6.6
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Given:

      require 'thread'
      require 'jruby'
      
      mutex = Mutex.new
      mutex.lock
      
      t = Thread.new do
        mutex.synchronize {}
      end
      
      Thread.pass until t.status == "sleep"
      
      JRuby.reference(t).native_thread.interrupt
      t.join
      

      Produces:

      ThreadError: Mutex is not owned by calling thread
        __file__ at ./test.rb:10
            call at org/jruby/RubyProc.java:270
            call at org/jruby/RubyProc.java:224
      

        Activity

        Hide
        Charles Oliver Nutter added a comment -

        This was simpler than I expected. In the implementation of Mutex#synchronize, we had code like this:

        try {
          lock
          yield
        } finally {
          unlock
        }
        

        Unfortunately, if any exception were raised by lock, we would still try to unlock, causing the errors you saw. Moving lock out of the try section fixes the problem, and you'll consistently see the Ruby ConcurrencyError instead.

        Whether we should be propagating the InterruptedException rather than rethrowing our own is up for debate. This is intended as a Ruby API, though, so we generally need to have Ruby exceptions.

        Fixed on master@978c0a4 and jruby-1_6@9bc7d7d.

        Show
        Charles Oliver Nutter added a comment - This was simpler than I expected. In the implementation of Mutex#synchronize, we had code like this: try { lock yield } finally { unlock } Unfortunately, if any exception were raised by lock, we would still try to unlock, causing the errors you saw. Moving lock out of the try section fixes the problem, and you'll consistently see the Ruby ConcurrencyError instead. Whether we should be propagating the InterruptedException rather than rethrowing our own is up for debate. This is intended as a Ruby API, though, so we generally need to have Ruby exceptions. Fixed on master@978c0a4 and jruby-1_6@9bc7d7d.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Dave Copeland
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: