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

Gregg Wonderly gregg at cytetech.com
Wed Aug 2 16:49:46 EDT 2006

Brian Goetz wrote:
>>In either case, I think there is considerable information to be gained from 
>>making sure that the cause is available.  I think that there is some merit to 
>>Dougs thoughts that there will eventually be a synchronized piece of code that 
>>runs and forces the visibility.
> JCiP coins the term "effectively immutable" for describing objects like 
> this -- they don't meet the definition of immutability, but they are 
> treated as if they were immutable forward from some point in time, and 
> this point is prior to publication.  For effectively immutable objects, 
> it is safe to use them without synchronization as long as they are 
> published (once) with synchronization.

Yes, and that's my point.  It's important for some of these core things to 
happen 'safely' so that developers are not sidetracked by the same, constantly 
recurring behavior which is difficult to track down.

Maybe I missed something.  Is it felt that there's no real value in 
synchronizing getCause() because subclasses might override it and not 
synchronize?  Is there a feeling that synchronizing getCause() would place some 
undue burden on JVM performance?

Gregg Wonderly

More information about the Concurrency-interest mailing list