use sync.RWMutex when masterNode changes
No need for this. Only one goroutine will be changing this value.
But other goroutine will read this value.
I wrote two programs to check if safe.
It turns out go run notlock.go will go wrong(get stuck) after running 2 minutes.
And go run lock.go is always running ok .
go run notlock.go
go run lock.go
So I think it is not safe, when one goroutine is writing a variable and other goroutines read it without locking.
So I think you need this pull request.
I do not understand the test. Does it mean g.a will be read wrongly? Wrongly means totally wrong data or just stale data? Stale data is fine for current bug, since the thread to check correct master node only runs every few seconds.
Not about stale data, it is about something unexpected will happen when concurrent access without sync.
If it is safe for one goroutine writing when another goroutine reading without sync,
so what do you think of sync.RWMutex is made for ?
"Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access.
To serialize access, protect the data with channel operations or other synchronization primitives such as those in the sync and sync/atomic packages."
We have one thread that's basically swapping one string value to another. This is a copy on write operation. Maybe check this page, which explains better than I do: http://en.wikipedia.org/wiki/Copy-on-write
I know the conception of COW, but I don't know what is the relation between COW and this concurrency-safety issue.
I guess your thoughts is "it is safe because masterNode is a string ", isn't it ?
So I wanna ask you a question , is it safe when masterNode is a int or map ?
i got "Failed to write to replicas for volume 3" too and it leads me here. not know much to the seaweedfs source but about the concurrency-safety, I think @yanyiwu is right, we need lock.
Please share your logs, setups.