[concurrency-interest] concurrency errors in java.lang.Throwable

Joe Bowbeer joe.bowbeer at gmail.com
Thu Aug 3 14:03:28 EDT 2006


On 8/2/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> Joe,
>
> getCause being synchronized would only be sufficient if the constructor
> used the synchronized initCause() - otherwise we'd need a volatile, or
> atomics or
>

Agreed.  In my original response to c-i, I said "one could argue" for
synchronizing getCause, but it wouldn't solve the problem.

Even without solving the problem, though, I thought it was desirable
to synchronize getCause -- for consistency.  But now I think
documentation is even more important.  Adding a "synchronized" that
won't fix anything may be just as confusing as leaving it out.

I still think using atomics is overkill unless there's a security vulnerability.

So I revise the work list to:

1. Declare detailMessage final.
2. Document why getCause isn't synchronized


I think it's also worth mentioning here that declaring cause as
volatile won't necessarily work.

Example from Jeremy Manson:

Thread 1:

// begin constructor
myThrowable.cause = this;
// end constructor
global = myThrowable;

Thread 2:

yourThrowable = global;
if (yourThrowable.cause == null)
  System.err.println("Null cause");

As Jeremy explains, the problem is that the assignment to global can
be hoisted above the write to cause (it isn't final).  In which case
the second thread won't see the appropriately initialized value of
cause.

--Joe


More information about the Concurrency-interest mailing list