use sync.map is better

[liu-song]

The same as the pull request of #1106 the fileslockmap read is more than write ,so sync.map will be better

[erikdubbelboer]

These are not the same I'm afraid. Something that went wrong in the previous pull request as well and was fixed here: 6d4db9b

With your new code it is possible for two goroutines to reach the exists == false state at the same time.

On way to fix this is to use LoadOrStore instead of just Load.

[liu-song]

Thanks for review ！
LoadOrStore will be better, I hava changed .here is my points about race condition,I'm not sure it's right，in this scenario when two goroutines reach the exists == false state at the same time, both of goroutines will store the value of *sync.Mutex, because of the implementation of the sync.map.store,there will be only one goroutine store success at the same time .
Another scenario , when two goroutine both return sync.Mutex to
https://github.com/valyala/fasthttp/blob/master/fs.go#L1124 , because of the implementation of the sync.mutex, there will only one goroutine get the mutex ,so it is safe for file when the value is mutex ? Is it different when the value of sync.map is *tcpAddrEntry to cause race condition?

[erikdubbelboer]

If both goroutines reach exists == false then only one of the mutexes will be stored in the map. But both goroutines will continue to lock their own mutex and think they have exclusive access to the file while they don't.

The tcpAddrEntry case is slightly different because it also checks some properties on it (.pending). That's why there I fixed it with an atomic check. Because of the use of atomic there only one goroutine will end up storing it's entry in the map.

[erikdubbelboer]

Thanks!