I know that happens-before does not imply happening before, can the code “A = B + 1; B = 1;” produce the...
In this article, the author mentions that "Happens-Before Does Not Imply Happening Before" and he shows an example to explain.
int A = 0;
int B = 0;
void foo()
{
A = B + 1; // (1)
B = 1; // (2)
}
He says that (2) can actually happen before (1), My question is that what will be the value of A if (2) actually happen before (1), 1 or 2?
java java-memory-model
asked Nov 12 at 15:00
Jason Law
178
|
show 1 more comment
In this article, the author mentions that "Happens-Before Does Not Imply Happening Before" and he shows an example to explain.
int A = 0;
int B = 0;
void foo()
{
A = B + 1; // (1)
B = 1; // (2)
}
He says that (2) can actually happen before (1), My question is that what will be the value of A if (2) actually happen before (1), 1 or 2?
java java-memory-model
asked Nov 12 at 15:00
Jason Law
178
5
"He says that (2) can actually happen before (1)" - that's incorrect. The order of evaluation would change the outcome of the operations, thus reordering it by the compiler is prohibited. By the way - which article?
– Fureeish
Nov 12 at 15:02
2
It will always be a==1, b==1. If a reordering happens, it's because it won't effect the answer. And he seems to talking about C++ in that article, although tries to make it language agnostic.
– Carcigenicate
Nov 12 at 15:07
@Fureeish I have edited the description, you can click this article to read that article.
– Jason Law
Nov 12 at 15:10
1
You tagged this question with "multithreading" and with "concurrency", but your example does not show any communication between threads. Within any single thread, everything that happens must be consistent with the program order of the statements that you wrote. Therefore, the function that callsfoo()when A and B both equal zero must see both A and B equal to 1 afterfoo()returns.
– Solomon Slow
Nov 12 at 15:45
1
"Happens before" rules only describe what happens when one thread observes actions that are taken by some other thread. If some other thread prints A and B, whilefoo()is being called, it is possible for the other thread to print A==0 and B==1. In the thread that callsfoo(), the assignment to A "happens before" the assignment to B, but nothing in your example would transfer that "happens before" relationship to any other thread. The other thread must eventually see A==1 and B==1, but it could see those two assignments happen in either order.
– Solomon Slow
Nov 12 at 15:53
|
show 1 more comment
In this article, the author mentions that "Happens-Before Does Not Imply Happening Before" and he shows an example to explain.
int A = 0;
int B = 0;
void foo()
{
A = B + 1; // (1)
B = 1; // (2)
}
He says that (2) can actually happen before (1), My question is that what will be the value of A if (2) actually happen before (1), 1 or 2?
java java-memory-model
asked Nov 12 at 15:00
Jason Law
178
In this article, the author mentions that "Happens-Before Does Not Imply Happening Before" and he shows an example to explain.
int A = 0;
int B = 0;
void foo()
{
A = B + 1; // (1)
B = 1; // (2)
}
He says that (2) can actually happen before (1), My question is that what will be the value of A if (2) actually happen before (1), 1 or 2?
java java-memory-model
java java-memory-model
asked Nov 12 at 15:00
Jason Law
178
asked Nov 12 at 15:00
Jason Law
178
edited Nov 12 at 17:41
asked Nov 12 at 15:00
Jason Law
178
asked Nov 12 at 15:00
Jason Law
178
asked Nov 12 at 15:00
Jason Law
178
178
5
"He says that (2) can actually happen before (1)" - that's incorrect. The order of evaluation would change the outcome of the operations, thus reordering it by the compiler is prohibited. By the way - which article?
– Fureeish
Nov 12 at 15:02
2
It will always be a==1, b==1. If a reordering happens, it's because it won't effect the answer. And he seems to talking about C++ in that article, although tries to make it language agnostic.
– Carcigenicate
Nov 12 at 15:07
@Fureeish I have edited the description, you can click this article to read that article.
– Jason Law
Nov 12 at 15:10
1
You tagged this question with "multithreading" and with "concurrency", but your example does not show any communication between threads. Within any single thread, everything that happens must be consistent with the program order of the statements that you wrote. Therefore, the function that callsfoo()when A and B both equal zero must see both A and B equal to 1 afterfoo()returns.
– Solomon Slow
Nov 12 at 15:45
1
"Happens before" rules only describe what happens when one thread observes actions that are taken by some other thread. If some other thread prints A and B, whilefoo()is being called, it is possible for the other thread to print A==0 and B==1. In the thread that callsfoo(), the assignment to A "happens before" the assignment to B, but nothing in your example would transfer that "happens before" relationship to any other thread. The other thread must eventually see A==1 and B==1, but it could see those two assignments happen in either order.
– Solomon Slow
Nov 12 at 15:53
|
show 1 more comment
5
"He says that (2) can actually happen before (1)" - that's incorrect. The order of evaluation would change the outcome of the operations, thus reordering it by the compiler is prohibited. By the way - which article?
– Fureeish
Nov 12 at 15:02
2
It will always be a==1, b==1. If a reordering happens, it's because it won't effect the answer. And he seems to talking about C++ in that article, although tries to make it language agnostic.
– Carcigenicate
Nov 12 at 15:07
@Fureeish I have edited the description, you can click this article to read that article.
– Jason Law
Nov 12 at 15:10
1
You tagged this question with "multithreading" and with "concurrency", but your example does not show any communication between threads. Within any single thread, everything that happens must be consistent with the program order of the statements that you wrote. Therefore, the function that callsfoo()when A and B both equal zero must see both A and B equal to 1 afterfoo()returns.
– Solomon Slow
Nov 12 at 15:45
1
"Happens before" rules only describe what happens when one thread observes actions that are taken by some other thread. If some other thread prints A and B, whilefoo()is being called, it is possible for the other thread to print A==0 and B==1. In the thread that callsfoo(), the assignment to A "happens before" the assignment to B, but nothing in your example would transfer that "happens before" relationship to any other thread. The other thread must eventually see A==1 and B==1, but it could see those two assignments happen in either order.
– Solomon Slow
Nov 12 at 15:53
5
5
"He says that (2) can actually happen before (1)" - that's incorrect. The order of evaluation would change the outcome of the operations, thus reordering it by the compiler is prohibited. By the way - which article?
– Fureeish
Nov 12 at 15:02
"He says that (2) can actually happen before (1)" - that's incorrect. The order of evaluation would change the outcome of the operations, thus reordering it by the compiler is prohibited. By the way - which article?
– Fureeish
Nov 12 at 15:02
2
2
It will always be a==1, b==1. If a reordering happens, it's because it won't effect the answer. And he seems to talking about C++ in that article, although tries to make it language agnostic.
– Carcigenicate
Nov 12 at 15:07
It will always be a==1, b==1. If a reordering happens, it's because it won't effect the answer. And he seems to talking about C++ in that article, although tries to make it language agnostic.
– Carcigenicate
Nov 12 at 15:07
@Fureeish I have edited the description, you can click this article to read that article.
– Jason Law
Nov 12 at 15:10
@Fureeish I have edited the description, you can click this article to read that article.
– Jason Law
Nov 12 at 15:10
1
1
You tagged this question with "multithreading" and with "concurrency", but your example does not show any communication between threads. Within any single thread, everything that happens must be consistent with the program order of the statements that you wrote. Therefore, the function that calls
foo() when A and B both equal zero must see both A and B equal to 1 after foo() returns.– Solomon Slow
Nov 12 at 15:45
You tagged this question with "multithreading" and with "concurrency", but your example does not show any communication between threads. Within any single thread, everything that happens must be consistent with the program order of the statements that you wrote. Therefore, the function that calls
foo() when A and B both equal zero must see both A and B equal to 1 after foo() returns.– Solomon Slow
Nov 12 at 15:45
1
1
"Happens before" rules only describe what happens when one thread observes actions that are taken by some other thread. If some other thread prints A and B, while
foo() is being called, it is possible for the other thread to print A==0 and B==1. In the thread that calls foo(), the assignment to A "happens before" the assignment to B, but nothing in your example would transfer that "happens before" relationship to any other thread. The other thread must eventually see A==1 and B==1, but it could see those two assignments happen in either order.– Solomon Slow
Nov 12 at 15:53
"Happens before" rules only describe what happens when one thread observes actions that are taken by some other thread. If some other thread prints A and B, while
foo() is being called, it is possible for the other thread to print A==0 and B==1. In the thread that calls foo(), the assignment to A "happens before" the assignment to B, but nothing in your example would transfer that "happens before" relationship to any other thread. The other thread must eventually see A==1 and B==1, but it could see those two assignments happen in either order.– Solomon Slow
Nov 12 at 15:53
|
show 1 more comment
2 Answers
2
active
oldest
votes
A and B are locations in memory. However the operation B+1 does not happen in memory, it happens in the CPU. Specifically, the author is describing these two operations.
A = B + 1 (1)
- A1 - The value in memory location
B(0) is loaded into a CPU register - A2 - The CPU register is incremented by
1
- A3 - The value in the CPU register (
1) is written to memory locationA
B = 1 (2)
- B1 - The value
1is written to memory locationB
Happens-Before requires that the read of B (step A1) happens before the write of B (step B1). However, the rest of the operations have no interdependence and can be reordered without affecting the result. Any of these sequences will produce the same outcome
- A1, B1, A2, A3
- A1, A2, B1, A3
- A1, A2, A3, B1
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
add a comment |
The author seems to mean that order of execution doesn't have to match the order in which the statements are written.
Reordering of program actions can be performed by either the JVM or the CPU, both of which you have little control of.
The point is that in Java you can only rely on what the Java Memory Model guarantees, and not the order of statements in your source code.
answered Nov 12 at 15:12
Malt
16.2k33962
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53264829%2fi-know-that-happens-before-does-not-imply-happening-before-can-the-code-a-b%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
A and B are locations in memory. However the operation B+1 does not happen in memory, it happens in the CPU. Specifically, the author is describing these two operations.
A = B + 1 (1)
- A1 - The value in memory location
B(0) is loaded into a CPU register - A2 - The CPU register is incremented by
1
- A3 - The value in the CPU register (
1) is written to memory locationA
B = 1 (2)
- B1 - The value
1is written to memory locationB
Happens-Before requires that the read of B (step A1) happens before the write of B (step B1). However, the rest of the operations have no interdependence and can be reordered without affecting the result. Any of these sequences will produce the same outcome
- A1, B1, A2, A3
- A1, A2, B1, A3
- A1, A2, A3, B1
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
add a comment |
A and B are locations in memory. However the operation B+1 does not happen in memory, it happens in the CPU. Specifically, the author is describing these two operations.
A = B + 1 (1)
- A1 - The value in memory location
B(0) is loaded into a CPU register - A2 - The CPU register is incremented by
1
- A3 - The value in the CPU register (
1) is written to memory locationA
B = 1 (2)
- B1 - The value
1is written to memory locationB
Happens-Before requires that the read of B (step A1) happens before the write of B (step B1). However, the rest of the operations have no interdependence and can be reordered without affecting the result. Any of these sequences will produce the same outcome
- A1, B1, A2, A3
- A1, A2, B1, A3
- A1, A2, A3, B1
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
add a comment |
A and B are locations in memory. However the operation B+1 does not happen in memory, it happens in the CPU. Specifically, the author is describing these two operations.
A = B + 1 (1)
- A1 - The value in memory location
B(0) is loaded into a CPU register - A2 - The CPU register is incremented by
1
- A3 - The value in the CPU register (
1) is written to memory locationA
B = 1 (2)
- B1 - The value
1is written to memory locationB
Happens-Before requires that the read of B (step A1) happens before the write of B (step B1). However, the rest of the operations have no interdependence and can be reordered without affecting the result. Any of these sequences will produce the same outcome
- A1, B1, A2, A3
- A1, A2, B1, A3
- A1, A2, A3, B1
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
A and B are locations in memory. However the operation B+1 does not happen in memory, it happens in the CPU. Specifically, the author is describing these two operations.
A = B + 1 (1)
- A1 - The value in memory location
B(0) is loaded into a CPU register - A2 - The CPU register is incremented by
1
- A3 - The value in the CPU register (
1) is written to memory locationA
B = 1 (2)
- B1 - The value
1is written to memory locationB
Happens-Before requires that the read of B (step A1) happens before the write of B (step B1). However, the rest of the operations have no interdependence and can be reordered without affecting the result. Any of these sequences will produce the same outcome
- A1, B1, A2, A3
- A1, A2, B1, A3
- A1, A2, A3, B1
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
answered Nov 12 at 21:54
Devon_C_Miller
14.7k13262
14.7k13262
add a comment |
add a comment |
The author seems to mean that order of execution doesn't have to match the order in which the statements are written.
Reordering of program actions can be performed by either the JVM or the CPU, both of which you have little control of.
The point is that in Java you can only rely on what the Java Memory Model guarantees, and not the order of statements in your source code.
answered Nov 12 at 15:12
Malt
16.2k33962
add a comment |
The author seems to mean that order of execution doesn't have to match the order in which the statements are written.
Reordering of program actions can be performed by either the JVM or the CPU, both of which you have little control of.
The point is that in Java you can only rely on what the Java Memory Model guarantees, and not the order of statements in your source code.
answered Nov 12 at 15:12
Malt
16.2k33962
add a comment |
The author seems to mean that order of execution doesn't have to match the order in which the statements are written.
Reordering of program actions can be performed by either the JVM or the CPU, both of which you have little control of.
The point is that in Java you can only rely on what the Java Memory Model guarantees, and not the order of statements in your source code.
answered Nov 12 at 15:12
Malt
16.2k33962
The author seems to mean that order of execution doesn't have to match the order in which the statements are written.
Reordering of program actions can be performed by either the JVM or the CPU, both of which you have little control of.
The point is that in Java you can only rely on what the Java Memory Model guarantees, and not the order of statements in your source code.
answered Nov 12 at 15:12
Malt
16.2k33962
edited Nov 12 at 15:20
answered Nov 12 at 15:12
Malt
16.2k33962
answered Nov 12 at 15:12
Malt
16.2k33962
answered Nov 12 at 15:12
Malt
16.2k33962
16.2k33962
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53264829%2fi-know-that-happens-before-does-not-imply-happening-before-can-the-code-a-b%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
5
"He says that (2) can actually happen before (1)" - that's incorrect. The order of evaluation would change the outcome of the operations, thus reordering it by the compiler is prohibited. By the way - which article?
– Fureeish
Nov 12 at 15:02
2
It will always be a==1, b==1. If a reordering happens, it's because it won't effect the answer. And he seems to talking about C++ in that article, although tries to make it language agnostic.
– Carcigenicate
Nov 12 at 15:07
@Fureeish I have edited the description, you can click this article to read that article.
– Jason Law
Nov 12 at 15:10
1
You tagged this question with "multithreading" and with "concurrency", but your example does not show any communication between threads. Within any single thread, everything that happens must be consistent with the program order of the statements that you wrote. Therefore, the function that calls
foo()when A and B both equal zero must see both A and B equal to 1 afterfoo()returns.– Solomon Slow
Nov 12 at 15:45
1
"Happens before" rules only describe what happens when one thread observes actions that are taken by some other thread. If some other thread prints A and B, while
foo()is being called, it is possible for the other thread to print A==0 and B==1. In the thread that callsfoo(), the assignment to A "happens before" the assignment to B, but nothing in your example would transfer that "happens before" relationship to any other thread. The other thread must eventually see A==1 and B==1, but it could see those two assignments happen in either order.– Solomon Slow
Nov 12 at 15:53