[concurrency-interest] dealing with people that questionvisibility problems
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
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
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
More information about the Concurrency-interest