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
map write flag is shouldn't be set if the key in the map doesn't exist.
What did you see instead?
map write flag is set when deleting an item even if the key doesn't exist in the map.
What did you do?
The issue arises when 2 goroutines access the map at the same time. The first reads an item from the map, and the second deletes a key from it. Even if no key is found and no write was made, the reading goroutine will suffer concurrent read-write since the write flag is turned on before we check to see if the key exists.
Few lines before it is mentioned the write flag is turned on only after t.hasher ran since it may panic and no commit (write) will be made. This problem I suggested is similar.
The text was updated successfully, but these errors were encountered:
The issue arises when 2 goroutines access the map at the same time. The first reads an item from the map, and the second deletes a key from it. Even if no key is found and no write was made
Why would you want to do this in the first place, though? At best, it makes no sense. At worst, it's considered a data race, which is why the runtime panics.
Concurrently reading and attempting to write or delete a key from a map is a data race. The data race detection during normal runtime is best effort and might not trigger for all data races. https://golang.org/doc/faq#atomic_maps
The runtime race detection is a tradeoff between simplicity, performance and race detection. There are cases e.g. for uninitialised maps were the map runtime race detection might not trigger however if run with race instrumentation those cases might still be detected as data races. https://golang.org/doc/articles/race_detector.html
If the goroutine attempting deletion is known always to not delete a key to goroutine does not need to try to delete the key. If the goroutine sometimes actually deletes a key then this will trigger a data race warning even if the map implementation is changed to not set the hashWriting flag when no actual internal structure is changed.
In the current implementation there might not be a write to internal data structures but in the future there might be e.g. for bookkeeping and internal reorgantzaiion of the map for shrinking (even if no key was found).
What version of Go are you using (
go version
)?go1.13 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?What did you expect to see?
map write flag is shouldn't be set if the key in the map doesn't exist.
What did you see instead?
map write flag is set when deleting an item even if the key doesn't exist in the map.
What did you do?
The issue arises when 2 goroutines access the map at the same time. The first reads an item from the map, and the second deletes a key from it. Even if no key is found and no write was made, the reading goroutine will suffer concurrent read-write since the write flag is turned on before we check to see if the key exists.
go/src/runtime/map.go
Line 709 in 11f92e9
Few lines before it is mentioned the write flag is turned on only after t.hasher ran since it may panic and no commit (write) will be made. This problem I suggested is similar.
The text was updated successfully, but these errors were encountered: