You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These instructions compile to the following assembly instructions, without any prior lock:
mov from memory into register;
<binary_operation> (e.g. xor, and, ...);
mov from register back into memory.
These instructions, as well as the checks above them, are not guaranteed to be atomic.
As a consequence, we may have (rare but some) cases were a concurrent access is not detected.
The text was updated successfully, but these errors were encountered:
This is ok as is, I think. The checks that this flag enables are best effort. They are intended to help catch races in user programs, but there are no guarantees.
Accesses which would cause problems, like simultaneous writes to a map, are already forbidden by the language spec.
What version of Go are you using (
go version
)?master
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?Any.
What did you do?
Inspect runtime map for concurrent access checks. I am not talking about
sync.map
.What did you expect to see?
hashWriting
flag (un)set with atomic operations.What did you see instead?
Non atomic operations like in those lines:
mapaccess flag set,
mapaccess flag reset.
These instructions compile to the following assembly instructions, without any prior lock:
mov
from memory into register;<binary_operation>
(e.g.xor
,and
, ...);mov
from register back into memory.These instructions, as well as the checks above them, are not guaranteed to be atomic.
As a consequence, we may have (rare but some) cases were a concurrent access is not detected.
The text was updated successfully, but these errors were encountered: