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

[dev only] Double require bug in the handling of concurrent requires

    Details

    • Number of attachments :
      0

      Description

      Under the situation of concurrent requires, if the first require exits with an Exception (that means the feature is not marked as already required), second and third requires by Threads runs parallel even if both have a lock. It's because we remove the lock from pool at the Exception.

      cf. http://bugs.ruby-lang.org/issues/5754

        Activity

        Hide
        Hiroshi Nakamura added a comment -

        It's a bug introduced by fixing JRUBY-3194 (proper require protection and thread-safe autoload)

        Show
        Hiroshi Nakamura added a comment - It's a bug introduced by fixing JRUBY-3194 (proper require protection and thread-safe autoload)
        Hide
        Hiroshi Nakamura added a comment -

        Fixed at master. jruby-1_6 is safe because JRUBY-3194 and related fixes are not backported.

        JRUBY-6278: Double require bug in the handling of concurrent requires
        
        Try to re-acquire the lock if the locked object is not in the pool after
        locking.  The locked object may removed from the pool by precedent
        Thread.
        
        Way to fix in other impls.
          CRuby: check if another Thread is trying to acquire the lock before 
                 removing the lock from the pool.  GVL saves everything.
          Rubinius: Get the object from the pool, then tries to lock.  I think
                    there's a race here.
        
        Show
        Hiroshi Nakamura added a comment - Fixed at master. jruby-1_6 is safe because JRUBY-3194 and related fixes are not backported. JRUBY-6278: Double require bug in the handling of concurrent requires Try to re-acquire the lock if the locked object is not in the pool after locking. The locked object may removed from the pool by precedent Thread. Way to fix in other impls. CRuby: check if another Thread is trying to acquire the lock before removing the lock from the pool. GVL saves everything. Rubinius: Get the object from the pool, then tries to lock. I think there's a race here.
        Hide
        Hiroshi Nakamura added a comment -

        The previous fix was incomplete. Updated.

        JRUBY-6278: Double require bug in the handling of concurrent requires
        
        Try to re-acquire the lock if the locked object is not in the pool after
        locking.  The locked object may removed from the pool by precedent
        Thread.
        
        How other impls fixes it.
        
        CRuby: check if another Thread is trying to acquire the lock before
               removing the lock from the pool.  GVL saves everything.
        Rubinius: Get the object from the pool, then tries to lock.  I think
                  there's a race here.
        
        The difference from the previous fix (6c67f35b) is the existence check 
        of the pool after acquiring the lock.  The previous fix checks if it's
        null or not, but under heavy concurrent situation, later Threads may 
        update the lock in the pool.  So we need to check if it's the same 
        object or not.
        
        Show
        Hiroshi Nakamura added a comment - The previous fix was incomplete. Updated. JRUBY-6278: Double require bug in the handling of concurrent requires Try to re-acquire the lock if the locked object is not in the pool after locking. The locked object may removed from the pool by precedent Thread. How other impls fixes it. CRuby: check if another Thread is trying to acquire the lock before removing the lock from the pool. GVL saves everything. Rubinius: Get the object from the pool, then tries to lock. I think there's a race here. The difference from the previous fix (6c67f35b) is the existence check of the pool after acquiring the lock. The previous fix checks if it's null or not, but under heavy concurrent situation, later Threads may update the lock in the pool. So we need to check if it's the same object or not.

          People

          • Assignee:
            Hiroshi Nakamura
            Reporter:
            Hiroshi Nakamura
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: