[concurrency-interest] How seriously should we take brokendoublechecked idiom

Boehm, Hans hans.boehm at hp.com
Tue May 3 17:27:38 EDT 2005


A lot of my concern in ignoring such correctness issues
would be that once you go down that road at all, you
no longer know whether a given failure is expected or not,
making it much harder to diagnose even the unrelated ones.
When you see a highly intermittent failure, it's hard enough
to try to reason backwards about what might have caused it,
without also considering the impact of intentional
"low probability" bugs.

It's much harder to reason about failure "probabilities"
than to argue that something is correct.  Especially when
these aren't real probabilities.  Something that fails 1
in a zillion times now during testing, may fail every other
time next time somebody releases a new OS kernel with a
different thread scheduler, or when someone releases a
new machine with different timing characteristics.

You really don't want to go there intentionally.
Concurrent systems tend to have more than enough of these
problems without intentionally adding more.  Especially
when it's cheap to avoid.

Once you stop aiming for 100% correctness, things get very
complicated.

As you suggest, on hardware with weak memory ordering, there
is no practical way for a JVM to ensure that double-checked
locking works without the volatile declaration.  VMs
will not support it for backward compatibility because they
can't, at least not on platforms like PowerPC or Itanium.  

Hans

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu 
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf 
> Of Dawid Kurzyniec
> Sent: Tuesday, May 03, 2005 11:46 AM
> Cc: concurrency-interest at altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] How seriously should we 
> take brokendoublechecked idiom
> 
> 
> Bill Pugh wrote:
> 
> > Please tell me what project you work on so I can avoid it, or what
> > company you work for so I can short your stock.
> >
> > Like others, I am appalled at your tech lead's attitude towards
> > software reliability.
> >
> > There is essentially no cost to performing thread-safe lazy
> > initialization in a correct way, and several
> > possible correct ways to accomplish it.
> >
> Not trying to argue with what you guys say and suggest as 
> alternatives, 
> I think you might be a bit too harsh in reacting to the 
> question. After 
> all, "double checked locking" idiom was once blessed and recommended, 
> and, correct me if I am wrong, but I think I have seen 
> several uses of 
> it in core Java classes. It will take time and patience to educate 
> people that it is not correct; also, I can understand that people may 
> count that the idiom will work on SUN JVMs even though not 
> guaranteed by 
> the spec, just because SUN once was using it in its own code. Even 
> though this expectation may be unjustified, especially on SMP 
> machines, 
> still - educating (and especially un-educating) people always 
> takes time 
> and patience. Also, after all, the fact that this question 
> was asked on 
> this forum suggests that the company might actually be quite sane :)
> 
> Just my 2c,
> Regards,
> Dawid Kurzyniec
> 
> _______________________________________________
> Concurrency-interest mailing list 
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> 



More information about the Concurrency-interest mailing list