commit	5e6c93348c4250012801b6e41753789d760f06e4	[log] [tgz]
author	timofeyb <timofeyb@google.com>	Mon Apr 20 12:45:07 2015 -0700
committer	Sam Berlin <sameb@google.com>	Tue Apr 21 09:37:16 2015 -0400
tree	604e25005690d696b2a7ee8ac39273aca98af3b4
parent	6c85843a85100c01992a1f3c6a16bb9270055d84 [diff]

Implement more granular locks for a Singleton scope in Guice.

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

19 files changed

tree: 604e25005690d696b2a7ee8ac39273aca98af3b4

README.md

Guice

Now, out in 4.0 Beta5!

Documentation: User Guide, 3.0 javadocs, Latest javadocs
Continuous Integration:
Mailing Lists: User Mailing List, Developer Mailing List
License: Apache 2.0

Put simply, Guice alleviates the need for factories and the use of new in your Java code. Think of Guice's @Inject as the new new. You will still need to write factories in some cases, but your code will not depend directly on them. Your code will be easier to change, unit test and reuse in other contexts.

Guice embraces Java's type safe nature, especially when it comes to features introduced in Java 5 such as generics and annotations. You might think of Guice as filling in missing features for core Java. Ideally, the language itself would provide most of the same features, but until such a language comes along, we have Guice.

Guice helps you design better APIs, and the Guice API itself sets a good example. Guice is not a kitchen sink. We justify each feature with at least three use cases. When in doubt, we leave it out. We build general functionality which enables you to extend Guice rather than adding every feature to the core framework.

Guice aims to make development and debugging easier and faster, not harder and slower. In that vein, Guice steers clear of surprises and magic. You should be able to understand code with or without tools, though tools can make things even easier. When errors do occur, Guice goes the extra mile to generate helpful messages.

For an introduction to Guice and a comparison to new and the factory pattern, see Bob Lee's video presentation. After that, check out our user's guide.

We've been running Guice in mission critical applications since 2006, and now you can, too. We hope you enjoy it as much as we do.