digifer (10) [Avatar] Offline
#1
List 6.21, race_condition.nim, always seems to produce the correct value on Windows, when I compile using the release flag.

I suspect that the race condition is optimized out of existence, but haven't understood the generated c code well enough to be sure. I have not tried other platforms either.

I would suggest emphasizing that it needs to be built without the release flag for the effect to show up.
dom96 (75) [Avatar] Offline
#2
Thank you for reporting this.

Sadly I think we're too far into the development process of this book to modify chapter 6. Hopefully it won't confuse anyone too much.
digifer (10) [Avatar] Offline
#3
I reproduced the bug due to the race condition even in release. I got 10000 instead of the expected 20000.

The loop in c is actually just a faithful translation of the nim loop. So what I suspect is happening is that the incrementing loop is compiled out of existence by the c compiler, so it becomes simply
counter += 10000


This would explain the behaviour, as the increment is of course not atomic. And the behaviour is obviously rare, because you only have a tiny chance of collision when the increment is only done once.
digifer (10) [Avatar] Offline
#4
Thanks for the reply, Dominik!

I understand it might be too late, but I would just suggest the following change on bottom of page 189:
"Save listing 6.21 as race_condition.nim , then compile and run it."
instead becomes
"Save listing 6.21 as race_condition.nim , then compile it without the -d:release flag and run it."

This will give the reader a hint about how this works if they then try it with the release flag.

Or possibly
"Save listing 6.21 as race_condition.nim , then compile it without the -d:release flag and run it. We skip the release flag so that the compiler does not do optimizations that might affect the example"
dom96 (75) [Avatar] Offline
#5
I will send this to my editor and see what can be done smilie