On Monday, 6 June 2016 00:37:50 UTC+3, Richard Todd wrote:
On Sunday, June 5, 2016 at 3:06:31 PM UTC-5, Jan Mercl wrote:

However, the compiler is, according to the memory model, completely free
to, for example, inline the isReady fumnction and then never read the
'ready' variable again inside the for loop in code like this:

if isReady() {
for !isReady() {
Oh for sure, I get that Go doesn't have a "volatile"-type keyword to help
you in cases like this, and never intended to imply you could forget locks
in general.
Note, volatile (in C) doesn't help you in that case either (not always at

One example from http://blog.regehr.org/archives/28

volatile int ready;
int message[100];

void foo (int i) {
   message[i/10] = 42;
   ready = 1;

would compile into this with gcc:

         mov eax, edi
         mov edx, 1717986919
         sar edi, 31
         imul edx
         mov DWORD PTR ready[rip], 1
         sar edx, 2
         sub edx, edi
         movsx rdx, edx
         mov DWORD PTR message[0+rdx*4], 42

Basically the compiler optimizes the code such that looks like:

void foo (int i) {
   ready = 1;
   message[i/10] = 42;

I just read through the memory model document, and I'm a bit surprised that
Go won't even promise you'll see a write from another goroutine at all.
I'm assuming in practice that only happens via loop optimizations on the
writer's side, but regardless they clearly don't want you to try to be
clever. So, point taken.

Thanks for your help!
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 26 | next ›
Discussion Overview
groupgolang-nuts @
postedJun 5, '16 at 2:39p
activeJun 8, '16 at 2:24p



site design / logo © 2021 Grokbase