Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve "is allowed to observe" definition in Go Memory Model documentation #3144

Closed
gopherbot opened this issue Feb 27, 2012 · 6 comments
Closed

Comments

@gopherbot
Copy link

by hanbing.liu:

What steps will reproduce the problem?
1. Check http://golang.org/doc/go_mem.html 

On "is allowed to observe": 

"""
A read r of a variable v is allowed to observe a write w to v if both of the following
hold:

    w happens before r.
    There is no other write w' to v that happens after w but before r.
"""

What is the expected output?
""" 
   A read r of a variable v is allowed to observe a write w to v if
   both of the following hold:
    1. w happens before r.
    2. There is no other write w' to v that happens after w but before r.

   A read r of a variable v is also allowed to observe a write w to v if w happens concurrently with r.

   If a w does not fit into either of these two cases,  a read r of
   variable v is not allowed to observe the write w to v.
"""

What do you see instead?

"""
A read r of a variable v is allowed to observe a write w to v if both of the following
hold:

    w happens before r.
    There is no other write w' to v that happens after w but before r.
"""

Which compiler are you using (5g, 6g, 8g, gccgo)?

N/A


Which operating system are you using?
N/A

Which revision are you using?  (hg identify)
N/A

Please provide any additional information below.

The existing statement concerning "is allowed to observe" meant to define what
are the possible set of w that may provide the value seen by the r. 

Broadly there are three types of w. (1) those w that happens-before r (2) those w that w
happens-after s (3) those w that happens concurrently with r. 

The existing statement only says what subset of w from (1) is allowed to by observed by
r. 

My revision, will be more explicit on the intended definition of "is allowed to
observe".

Thanks.
@dsymonds
Copy link
Contributor

Comment 1:

Labels changed: added priority-later, documentation, removed priority-triage.

@rsc
Copy link
Contributor

rsc commented Feb 28, 2012

Comment 2:

I believe this is fixed at tip.  
See http://weekly.golang.org/doc/go_mem.html

Status changed to Duplicate.

Merged into issue #2777.

@gopherbot
Copy link
Author

Comment 3 by hanbing.liu:

Hi
   I don't see how this change was related to 2777.
  On the http://weekly.golang.org/doc/go_mem.html, the "is allowed to
observed" still only talks about
"""
  A read r of a variable v is allowed to observe a write w to v if
both of the following hold:
    r does not happen before w.
    There is no other write w' to v that happens after w but before r.
"""
  Russ,  if you are reading this :), you maybe remember an email
thread about this in last August.
  I think basically agreed that "It should add that a read r is also
allowed to observe any
write w that happens concurrently with r".

@rsc
Copy link
Contributor

rsc commented Feb 28, 2012

Comment 4:

I remember that email thread, and I remember the fix we made
as addressing it.  Can you describe a case that your new
wording would handle differently (and better) than the current
wording at tip?
Russ

@gopherbot
Copy link
Author

Comment 5 by hanbing.liu:

My apologies!
I just noticed that you changed  "w happens before r" into "r does not
happen before w".
The wording is good.  Thanks!
hanbing

@rsc
Copy link
Contributor

rsc commented Feb 29, 2012

Comment 6:

I see now why you were confused about the duplicate marking.  2277, not 2777.

Merged into issue #2277.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants