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.
david
>
> 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;
> >>}
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
>
> >>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 it
> >>
> >>makes
> >>
> >>>no 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. This
> >>
> >>is
> >>
> >>>not 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
>
>
-------------------------------------------------------
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
