Skip to content
Permalink
Branch: master
Commits on Oct 28, 2015
  1. Allowing two member injections happen in parallel.

    timofeyb authored and sameb committed Sep 23, 2015
    Initializer explicitly forbade using several threads
    with a single CountDownLatch.
    With this change there is no single lock for
    InjectableReferences. Each one still employs
    double locking to guarantee thread-safety and
    exactly once contract.
    
    As a side effect of this change:
    - requestInjection() explicitly checks that
      validateOutstandingInjections() were not called
      to simplify state reasoning
    - requestInjection() stores all requested
      injections in a list to enforce initialization
      ordering similar to static injections
    - potential for a deadlock when client uses several threads
      to initialize InjectableReferences
      with circular dependencies
    -------------
    Created by MOE: https://github.com/google/moe
    MOE_MIGRATED_REVID=103764508
  2. Bug: CycleDetectingLockFactory could dead lock.

    timofeyb authored and sameb committed Sep 17, 2015
    When several instances of a CycleDetectingLockFactory
    are used they could deadlock each other as they
    don't share locks information between each other.
    
    This is fixed by using shared storage for
    all factories instances.
    -------------
    Created by MOE: https://github.com/google/moe
    MOE_MIGRATED_REVID=103304752
Commits on Apr 21, 2015
  1. Implement more granular locks for a Singleton scope in Guice.

    timofeyb authored and sameb committed Apr 20, 2015
    Now when you can create two independent singletons using
    the same injector in different threads.
    This make it easy to create scopes creating singletons using
    thread pools with all the concurrency being done by Guice.
    As a nice side effect Singleton scope is no longer treated
    specially in Guice codebase.
    
    The obvious problem to solve is potential deadlocks:
    A requires B, B requires C, C requires A where all are
    singletons and all are created simultaneously.
    It's impossible to detect this deadlock using information
    within one thread, so we have to have a shared storage.
    
    An idea is to have a map of creators' locks and a map
    of which threads are waiting for other singletons to be created.
    Using this information circular dependencies are trivially
    discovered within O(N) where N is a number of concurrent threads.
    
    Important to not that no other deadlock scenarios within
    Guice code is introduced as Guice does not expose any
    other scopes that can span several threads.
    
    Now it would be possible for
    client code to deadlock on itself with two lazy singletons
    calling each other's providers during creation.
    This is deemed as a non-issue as it is up to the client
    to write a thread-safe code.
    -------------
    Created by MOE: http://code.google.com/p/moe-java
    MOE_MIGRATED_REVID=91610630
Commits on Oct 27, 2014
  1. Making Singleton's creation lock less coarse.

    timofeyb authored and sameb committed Oct 24, 2014
    Singleton is defined as a scope which creates no more than one
    object per injector. It's highly confusing when you catch a deadlock
    between two unrelated injectors due to the same class injection.
    
    Problem is demonstrated using a test that recreates scenario when
    one thread injecting class can block other thread to use its own
    injector.
    
    Proposed solution is to use Injector-wide locks in a singleton.
    ThreadLocal as a way to store current state.
    -------------
    Created by MOE: http://code.google.com/p/moe-java
    MOE_MIGRATED_REVID=78469951
You can’t perform that action at this time.