Mixing
Can a goroutine go to sleep during a fmt.Println call?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I was doing some debugging and had a bit of code like this:
go func() {
if !finished {
fmt.Println("Writing the data")
writer.Write(data)
}
}()
The finished variable is meant as a guard against writing to a writer that has been closed. However, it wasn't working. It appeared to be getting passed the flag. I determined that the call to Println was yielding the goroutine, which could allow the writer to be closed after checking the flag but before attempting the write. Sure enough, removing the call seems to have fixed it. However, I wanted to verify, and more importantly ask for suggestions on how to avoid this properly, rather than just avoiding prints in there.
go
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
add a comment |
I was doing some debugging and had a bit of code like this:
go func() {
if !finished {
fmt.Println("Writing the data")
writer.Write(data)
}
}()
The finished variable is meant as a guard against writing to a writer that has been closed. However, it wasn't working. It appeared to be getting passed the flag. I determined that the call to Println was yielding the goroutine, which could allow the writer to be closed after checking the flag but before attempting the write. Sure enough, removing the call seems to have fixed it. However, I wanted to verify, and more importantly ask for suggestions on how to avoid this properly, rather than just avoiding prints in there.
go
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
1
Have you run the Go race detector? Data Race Detector: golang.org/doc/articles/race_detector.html
– peterSO
Jan 3 at 4:12
1
You must use some proper synchronisation and you must never rely on a goroutines being or not being scheduled.
– Volker
Jan 3 at 4:40
Well that was essentially my question. I've done plenty of threading in C, but most of the async stuff I've worked on is in JavaScript, which does make guarantees about scheduling. Do you have a recommendation for a nice primer on proper synchronization in go?
– anderspitman
Jan 3 at 5:06
@peterSO, thanks for the suggestion. I wasn't aware of the race detector. I'll definitely start using it. Looks like it already detected another race in the project.
– anderspitman
Jan 3 at 5:10
add a comment |
I was doing some debugging and had a bit of code like this:
go func() {
if !finished {
fmt.Println("Writing the data")
writer.Write(data)
}
}()
The finished variable is meant as a guard against writing to a writer that has been closed. However, it wasn't working. It appeared to be getting passed the flag. I determined that the call to Println was yielding the goroutine, which could allow the writer to be closed after checking the flag but before attempting the write. Sure enough, removing the call seems to have fixed it. However, I wanted to verify, and more importantly ask for suggestions on how to avoid this properly, rather than just avoiding prints in there.
go
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
I was doing some debugging and had a bit of code like this:
go func() {
if !finished {
fmt.Println("Writing the data")
writer.Write(data)
}
}()
The finished variable is meant as a guard against writing to a writer that has been closed. However, it wasn't working. It appeared to be getting passed the flag. I determined that the call to Println was yielding the goroutine, which could allow the writer to be closed after checking the flag but before attempting the write. Sure enough, removing the call seems to have fixed it. However, I wanted to verify, and more importantly ask for suggestions on how to avoid this properly, rather than just avoiding prints in there.
go
go
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
asked Jan 3 at 3:32
anderspitmananderspitman
2,7252337
2,7252337
1
Have you run the Go race detector? Data Race Detector: golang.org/doc/articles/race_detector.html
– peterSO
Jan 3 at 4:12
1
You must use some proper synchronisation and you must never rely on a goroutines being or not being scheduled.
– Volker
Jan 3 at 4:40
Well that was essentially my question. I've done plenty of threading in C, but most of the async stuff I've worked on is in JavaScript, which does make guarantees about scheduling. Do you have a recommendation for a nice primer on proper synchronization in go?
– anderspitman
Jan 3 at 5:06
@peterSO, thanks for the suggestion. I wasn't aware of the race detector. I'll definitely start using it. Looks like it already detected another race in the project.
– anderspitman
Jan 3 at 5:10
add a comment |
1
Have you run the Go race detector? Data Race Detector: golang.org/doc/articles/race_detector.html
– peterSO
Jan 3 at 4:12
1
You must use some proper synchronisation and you must never rely on a goroutines being or not being scheduled.
– Volker
Jan 3 at 4:40
Well that was essentially my question. I've done plenty of threading in C, but most of the async stuff I've worked on is in JavaScript, which does make guarantees about scheduling. Do you have a recommendation for a nice primer on proper synchronization in go?
– anderspitman
Jan 3 at 5:06
@peterSO, thanks for the suggestion. I wasn't aware of the race detector. I'll definitely start using it. Looks like it already detected another race in the project.
– anderspitman
Jan 3 at 5:10
1
1
Have you run the Go race detector? Data Race Detector: golang.org/doc/articles/race_detector.html
– peterSO
Jan 3 at 4:12
Have you run the Go race detector? Data Race Detector: golang.org/doc/articles/race_detector.html
– peterSO
Jan 3 at 4:12
1
1
You must use some proper synchronisation and you must never rely on a goroutines being or not being scheduled.
– Volker
Jan 3 at 4:40
You must use some proper synchronisation and you must never rely on a goroutines being or not being scheduled.
– Volker
Jan 3 at 4:40
Well that was essentially my question. I've done plenty of threading in C, but most of the async stuff I've worked on is in JavaScript, which does make guarantees about scheduling. Do you have a recommendation for a nice primer on proper synchronization in go?
– anderspitman
Jan 3 at 5:06
Well that was essentially my question. I've done plenty of threading in C, but most of the async stuff I've worked on is in JavaScript, which does make guarantees about scheduling. Do you have a recommendation for a nice primer on proper synchronization in go?
– anderspitman
Jan 3 at 5:06
@peterSO, thanks for the suggestion. I wasn't aware of the race detector. I'll definitely start using it. Looks like it already detected another race in the project.
– anderspitman
Jan 3 at 5:10
@peterSO, thanks for the suggestion. I wasn't aware of the race detector. I'll definitely start using it. Looks like it already detected another race in the project.
– anderspitman
Jan 3 at 5:10
add a comment |
1 Answer
1
active
oldest
votes
Any I/O, yes, including fmt.Println, can cause a pause in goroutine execution.
But in practice, this shouldn't matter, as on any modern hardware, with more than one CPU core, you can experience a race even if the goroutine isn't paused.
You should always make your code concurrency safe.
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
Well that's assuming that it's running on multiple cores. The important part of my question is what's the idiomatic go way of protecting something like a writer within a goroutine?
– anderspitman
Jan 3 at 7:46
1
No, there's no assumption--the multiple cores case is explicitly stated.
– Flimzy
Jan 3 at 8:16
2
There are many ways to avoid it. Use a mutex. Use a channel. Don't use goroutines. The best approach depends on your application, but you haven't provided enough context to offer such a suggestion.
– Flimzy
Jan 3 at 8:17
Where did I state that I planned to run this on multiple cores? In many common concurrent systems (JavaScript, Python, etc), applications will be running on a single core, and code like I provided in my question would be perfectly safe. As a beginner in go, I'm trying to take what I already know, and see where go fits in and what the proper way to do things is.
– anderspitman
Jan 3 at 19:22
Your second comment is the actual answer to the question: basically go is like C/C++, and you should use the same techniques you would use there.
– anderspitman
Jan 3 at 19:23
|
show 2 more comments
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%2f54015990%2fcan-a-goroutine-go-to-sleep-during-a-fmt-println-call%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Any I/O, yes, including fmt.Println, can cause a pause in goroutine execution.
But in practice, this shouldn't matter, as on any modern hardware, with more than one CPU core, you can experience a race even if the goroutine isn't paused.
You should always make your code concurrency safe.
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
Well that's assuming that it's running on multiple cores. The important part of my question is what's the idiomatic go way of protecting something like a writer within a goroutine?
– anderspitman
Jan 3 at 7:46
1
No, there's no assumption--the multiple cores case is explicitly stated.
– Flimzy
Jan 3 at 8:16
2
There are many ways to avoid it. Use a mutex. Use a channel. Don't use goroutines. The best approach depends on your application, but you haven't provided enough context to offer such a suggestion.
– Flimzy
Jan 3 at 8:17
Where did I state that I planned to run this on multiple cores? In many common concurrent systems (JavaScript, Python, etc), applications will be running on a single core, and code like I provided in my question would be perfectly safe. As a beginner in go, I'm trying to take what I already know, and see where go fits in and what the proper way to do things is.
– anderspitman
Jan 3 at 19:22
Your second comment is the actual answer to the question: basically go is like C/C++, and you should use the same techniques you would use there.
– anderspitman
Jan 3 at 19:23
|
show 2 more comments
Any I/O, yes, including fmt.Println, can cause a pause in goroutine execution.
But in practice, this shouldn't matter, as on any modern hardware, with more than one CPU core, you can experience a race even if the goroutine isn't paused.
You should always make your code concurrency safe.
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
Well that's assuming that it's running on multiple cores. The important part of my question is what's the idiomatic go way of protecting something like a writer within a goroutine?
– anderspitman
Jan 3 at 7:46
1
No, there's no assumption--the multiple cores case is explicitly stated.
– Flimzy
Jan 3 at 8:16
2
There are many ways to avoid it. Use a mutex. Use a channel. Don't use goroutines. The best approach depends on your application, but you haven't provided enough context to offer such a suggestion.
– Flimzy
Jan 3 at 8:17
Where did I state that I planned to run this on multiple cores? In many common concurrent systems (JavaScript, Python, etc), applications will be running on a single core, and code like I provided in my question would be perfectly safe. As a beginner in go, I'm trying to take what I already know, and see where go fits in and what the proper way to do things is.
– anderspitman
Jan 3 at 19:22
Your second comment is the actual answer to the question: basically go is like C/C++, and you should use the same techniques you would use there.
– anderspitman
Jan 3 at 19:23
|
show 2 more comments
Any I/O, yes, including fmt.Println, can cause a pause in goroutine execution.
But in practice, this shouldn't matter, as on any modern hardware, with more than one CPU core, you can experience a race even if the goroutine isn't paused.
You should always make your code concurrency safe.
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
Any I/O, yes, including fmt.Println, can cause a pause in goroutine execution.
But in practice, this shouldn't matter, as on any modern hardware, with more than one CPU core, you can experience a race even if the goroutine isn't paused.
You should always make your code concurrency safe.
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
answered Jan 3 at 7:11
FlimzyFlimzy
40.6k1367101
40.6k1367101
Well that's assuming that it's running on multiple cores. The important part of my question is what's the idiomatic go way of protecting something like a writer within a goroutine?
– anderspitman
Jan 3 at 7:46
1
No, there's no assumption--the multiple cores case is explicitly stated.
– Flimzy
Jan 3 at 8:16
2
There are many ways to avoid it. Use a mutex. Use a channel. Don't use goroutines. The best approach depends on your application, but you haven't provided enough context to offer such a suggestion.
– Flimzy
Jan 3 at 8:17
Where did I state that I planned to run this on multiple cores? In many common concurrent systems (JavaScript, Python, etc), applications will be running on a single core, and code like I provided in my question would be perfectly safe. As a beginner in go, I'm trying to take what I already know, and see where go fits in and what the proper way to do things is.
– anderspitman
Jan 3 at 19:22
Your second comment is the actual answer to the question: basically go is like C/C++, and you should use the same techniques you would use there.
– anderspitman
Jan 3 at 19:23
|
show 2 more comments
Well that's assuming that it's running on multiple cores. The important part of my question is what's the idiomatic go way of protecting something like a writer within a goroutine?
– anderspitman
Jan 3 at 7:46
1
No, there's no assumption--the multiple cores case is explicitly stated.
– Flimzy
Jan 3 at 8:16
2
There are many ways to avoid it. Use a mutex. Use a channel. Don't use goroutines. The best approach depends on your application, but you haven't provided enough context to offer such a suggestion.
– Flimzy
Jan 3 at 8:17
Where did I state that I planned to run this on multiple cores? In many common concurrent systems (JavaScript, Python, etc), applications will be running on a single core, and code like I provided in my question would be perfectly safe. As a beginner in go, I'm trying to take what I already know, and see where go fits in and what the proper way to do things is.
– anderspitman
Jan 3 at 19:22
Your second comment is the actual answer to the question: basically go is like C/C++, and you should use the same techniques you would use there.
– anderspitman
Jan 3 at 19:23
Well that's assuming that it's running on multiple cores. The important part of my question is what's the idiomatic go way of protecting something like a writer within a goroutine?
– anderspitman
Jan 3 at 7:46
Well that's assuming that it's running on multiple cores. The important part of my question is what's the idiomatic go way of protecting something like a writer within a goroutine?
– anderspitman
Jan 3 at 7:46
1
1
No, there's no assumption--the multiple cores case is explicitly stated.
– Flimzy
Jan 3 at 8:16
No, there's no assumption--the multiple cores case is explicitly stated.
– Flimzy
Jan 3 at 8:16
2
2
There are many ways to avoid it. Use a mutex. Use a channel. Don't use goroutines. The best approach depends on your application, but you haven't provided enough context to offer such a suggestion.
– Flimzy
Jan 3 at 8:17
There are many ways to avoid it. Use a mutex. Use a channel. Don't use goroutines. The best approach depends on your application, but you haven't provided enough context to offer such a suggestion.
– Flimzy
Jan 3 at 8:17
Where did I state that I planned to run this on multiple cores? In many common concurrent systems (JavaScript, Python, etc), applications will be running on a single core, and code like I provided in my question would be perfectly safe. As a beginner in go, I'm trying to take what I already know, and see where go fits in and what the proper way to do things is.
– anderspitman
Jan 3 at 19:22
Where did I state that I planned to run this on multiple cores? In many common concurrent systems (JavaScript, Python, etc), applications will be running on a single core, and code like I provided in my question would be perfectly safe. As a beginner in go, I'm trying to take what I already know, and see where go fits in and what the proper way to do things is.
– anderspitman
Jan 3 at 19:22
Your second comment is the actual answer to the question: basically go is like C/C++, and you should use the same techniques you would use there.
– anderspitman
Jan 3 at 19:23
Your second comment is the actual answer to the question: basically go is like C/C++, and you should use the same techniques you would use there.
– anderspitman
Jan 3 at 19:23
|
show 2 more comments
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.
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%2f54015990%2fcan-a-goroutine-go-to-sleep-during-a-fmt-println-call%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
1
Have you run the Go race detector? Data Race Detector: golang.org/doc/articles/race_detector.html
– peterSO
Jan 3 at 4:12
1
You must use some proper synchronisation and you must never rely on a goroutines being or not being scheduled.
– Volker
Jan 3 at 4:40
Well that was essentially my question. I've done plenty of threading in C, but most of the async stuff I've worked on is in JavaScript, which does make guarantees about scheduling. Do you have a recommendation for a nice primer on proper synchronization in go?
– anderspitman
Jan 3 at 5:06
@peterSO, thanks for the suggestion. I wasn't aware of the race detector. I'll definitely start using it. Looks like it already detected another race in the project.
– anderspitman
Jan 3 at 5:10