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. 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);
}
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
Here, 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 the issues with this. I think this is a "double checked locking" idiom and I think it is just as broken.The guy who calls someOtherMethod will definitely see the correct hashmap, but there is no guarantee that its state will match any particular state in which 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 or remove it. 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;
}
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
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 does need to be modified.
I don't think this is as useful as it once was - synchronization is much 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 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
