On 2003.02.13 14:42 Larry Sanderson wrote:
> ... <do a bunch of reading on double checked locking> ...
>
> 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?
Not personally. I think they are unlikely to fail on single processor
machines but much more likely to fail on multiprocessor alpha boxes which I
believe have a very aggresive approach to cache synchronization with main
memory. I have no direct experience with any multiprocessor machines of
any kind.
How much performance gain
> do VM's really acheive by being allowed this much leniency in their
> memory management?
I have no idea, but it appears to be pretty fundamental to the meaning of
synchronize.
>
> Last question: does the typical JBoss developer know about this?
Based on todays discussion, apparently not.
david jencks
>
> 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.
> >
> > 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
>
>
>
> -------------------------------------------------------
> 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
