[concurrency-interest] dealing with people that questionvisibility problems

Gregg Wonderly gregg at cytetech.com
Wed Feb 21 23:39:21 EST 2007

David Holmes wrote:
> Gregg Wonderly wrote:
>>The issue that I see is that it is more possible to study code for a race
>>condition when you see the effects.  These are more readily
>>understood.  It is difficult to understand visibility related bugs
> It is difficult to uncover the fact that you have a visiblity related bug.
> But studying the code if you find a shared mutable variable that is not
> volatile and not accessed under synchronization, then you potentially have a
> visibility related bug.

I am not trying to dispute the facts David.  It is true that observation of "the 
code" can reveal to you that visibility is in question.  The observed bug will 
be lack of loop termination, in this case.  I contend that this is a red-herring 
which will potentially focus debugging outside of this code and to the callers 
of the setter and the associated flow control into the setter.

> Making all variables volatile fixes only pure-visibility bugs and in the
> process will totally kill performance by disallowing a slew of
> optimizations. 

This particular pattern is not a CPU bound pattern.  But, there are clearly 
others that will potentially suffer from recurring volatile references.

 > My contention is that it is more likely that there is an
> atomicity bug as well as a visibility bug, and that volatile won't help fix
>  it.

I've been greeted with numerous bugs to solve related to visibilty.  When I got 
a multi-core laptop to do my development on, old dependable software suddenly 
collapsed in a pile of bugs.  I don't recall ever having any atomicity bugs. 
I've always used Hashtable and Vector for containers.  The atomicity thing I've 
always had a grip on.

The visibility thing is something that I hadn't had any bad experiences with to 
help me understand what I should have been doing with synchronizing access to 
manage visibility (prior to volatile working).

 > In fact volatile could further obscure the bug by making it even less
> likely to appear in practice, such as during testing. Effective testing of
> concurrent programs benefits from the least allowed order, as this makes it
> easier to expose races.

I agree with this.  The more optimizations the compiler can make, the more 
ordering/visibility related issues you'll actually see.  This example is 
something that is a very common pattern due to "Thread.stop()" not being 
supported.  I think it's an important pattern to document as a "visibilty is 
important" example.

Gregg Wonderly

More information about the Concurrency-interest mailing list