JRuby

[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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: