[concurrency-interest] Problems understanding "visibility"

Jeremy Manson jmanson at cs.purdue.edu
Wed Oct 19 15:10:21 EDT 2005

Chris Purcell wrote:
> I'm having problems understanding this word "visibility" that keeps 
> getting used. Is it possible to create a concurrent program that can 
> actually tell the difference between acquire/release having only 
> ordering constraints, and acquire/release having ordering + visibility 
> constraints? Moreover, what concurrent design idioms require visibility 
> for correctness?

When you need visibility, you almost invariably need ordering, so 
release and acquire provide both.

The distinction mostly exists so we can describe separate symptoms of 
broken multithreaded code.  Here's an example of code with a data race 
exhibiting strange behavior with visibility, but without ordering:

Initially, p = q, p.x = 0;

Thread 1:
r1 = p.x;
r2 = q.x;
r3 = p.x;

Thread 2:
p.x = 1;

Let's pretend there was some way of getting visibility without ordering. 
  Somehow, we know that the write by Thread 2 will be seen by Thread 1. 
  But we aren't guaranteeing ordering.  It would be possible for the 
compiler to do the following:

Replacement Thread 1:
r1 = p.x;
r2 = q.x;
r3 = r1;

Let's say the write to p.x was scheduled between the read of p.x and the 
read of q.x by Thread 1.  In this case, you would get the result r1 = r3 
  0, r2 = 1.  In other words, the write was visible, but the results 
were seen out of order.

You could equally construct situations where you get ordering without 
visibility, but I think this illustrates the point.


More information about the Concurrency-interest mailing list