OK - I think I see where you are coming from now. Wow - I have to agree with Joshua Bloch: wildly counterintuitive. Have you ever experienced these things failing in the way you describe? How much performance gain do VM's really acheive by being allowed this much leniency in their memory management?
Last question: does the typical JBoss developer know about this?
Thanks for the info,
-Larry
David Jencks wrote:
On 2003.02.13 13:40 Larry Sanderson wrote:Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
foo = cache.get(cacheLooku);
if (foo == null) {
foo = new MyObject();
cache.put(cacheLookup, foo);
}
}
}
return foo;
}
I read an article in JavaWorld a long time ago that said this is not required to work in a legitimate JVM, even though it does on all known implementations. Unfortunately, I don't remember the how's or why's of
it.
However, this is not what the code below is all about.
Your example is way too complicated. You don't need a hashmap.
The normal example is:
private static Foo foo = null;
public static Foo getFoo() {
if (foo == null) {
synchronized (Foo.class) {
if (foo == null)
foo = new Foo();
}
}
return foo;
}
anyone calling getFoo without synchronization may observe the returned foo
in a partially initialized state.
I think the jboss code has the same problem as double checked locking --
described by Joshua Bloch as "wildly counterintuitive".
"But in the absence of synchronization, reading a "published" object
reference does not guarantee that a thread will see all of the data that
were stored in memory prior to the publication of the object reference. In
particular, reading a published object reference does not guarantee that
the reading thread will see the most recent values of the data that
constitute the internals of the referenced object."
In fact, you can
remove the synchronized block below and everything is still perfectly thread safe. The whole point is that the member variable "clients" is *NEVER* modified - only assigned to. In fact, it would drive the point home even more if you did this:
private Map clients = Collections.EMPTY_MAP;
public void someMethod()
{
HashMap localMap = null;
localMap = new HashMap(clients);
// ... read/write work on local map ...
clients = Collections.unmodifiableMap(localMap);
}
Unless Collections.unmodifiableMap is sychronized internally, the results from this are garbage.public void someOtherMethod() { HashMap localMap = clients; // ... read-only work on local map ... }I don't think localMap has a accurate view of clients unless this is synchronized. Just as with double-checked locking, it can read a partially initialized version of clients. davidHere, clients is always immutable, even though someMethod is able to update it with a new value. No synchronization, yet perfectly thread safe (although very expensive to modify).
-Larry
David Jencks wrote:
I think you are wrong, although I have trouble understanding all theissueswith this. I think this is a "double checked locking" idiom and Ithink itis just as broken. The guy who calls someOtherMethod will definitely see the correcthashmap,but there is no guarantee that its state will match any particularstate inwhich it was put unless access to it is also synchronized. Double checked locking is broken. See Effective Java pp 193 ff and the various Double Checked Locking is Broken websites. As I understand it, problems with this construct are unlikely to appear unless you are using something like a multiprocessor alpha box. I think we should prove in some way that this construct is safe orremoveit. david jencks On 2003.02.13 13:00 Larry Sanderson wrote:If the map is seldom modified, then you can get around synchronization with techniques like this. It is taking advantage of the fact that assignement is an atomic operation. If the methods are like this:
public void someMethod()
{
HashMap localMap = null;
synchronized (clients)
{
localMap = new HashMap(clients);
}
// ... read/write work on local map ...
clients = localMap;
}
Unless setting clients is synchronized, anyone reading clients will recieve a view of localMap in an inderminate state.public void someOtherMethod() { HashMap localMap = clients; // ... read-only work on local map ... }If clients is not read in a synchronized block, it is not guaranteed to be the same as ANY version that was set. It could be a half-written copy.Now everyone can call someOtherMethod() without invoking the cost of synchronization, and once they obtain localMap it is guaranteed not to be modified. But someMethod() exists for those rare times when the map
muchdoes need to be modified. I don't think this is as useful as it once was - synchronization is
faster than it used to be. -Larry Scott M Stark wrote:I have seen this usage construct in a few places in the code and itmakesno sense to me: class X { HashMap clients = new HashMap(); public void someMethod() { synchronized(clients) { HashMap m = new HashMap(clients); m.put(dc, cq); clients=m; } ... } public void someOtherMethod() { Iterator i = clients.keySet().iterator(); while( i.hasNext() ) { ... } } } The unsynchronized clients HashMap is synchronized and copied when modified and accessed without synchronization in other contexts. Thisisnot thread safe for the accesses and makes for very expensive updates. Why isn't the HashMap simply synchronized and used without copying? xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL securityissues.http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
