Storing data in a map involves a problem, that is, whether to store a value or a pointer.
#Gosync map free#
If the subsequent access to new elements is locked through mutex, the read-only map will be meaningless, sync.Map In order to provide lock free support for subsequent read access, the strategy of always delaying promotion is adopted to batch promote all elements in the current map to read-only map 2. By default, the added elements are placed in dirty. Delayed liftingĪs mentioned above, read-only map and dirty write map, There will be a problem. If multiple goroutine s are written at the same time, Mutex locking is required 2. Write locking and delay liftingĪs mentioned above, adding element operations may be added to dirty write map first. In fact, we only need to read the read map through atomic instructions without locking, so as to improve the performance of reading 3. If the map I read will not be expanded, I can have concurrent and secure access, and sync.map It is in this way that the added elements are saved by dirty 2. In fact, the main problem of concurrent access to map reading is that during the expansion, the elements may be hash ed to other addresses. In some cases, for example, when a large amount of data is added frequently at a certain time point, and then deleted in large quantities, the capacity of map will not shrink with the deletion of elements 5.
In Mutex and RWMutex, the capacity of map will increase with the increase and deletion of time and the number of elements. In most cases, it can replace the above two implementations In the bottom layer, the read-write map and atomic instructions are separated to achieve the approximate lock-free reading, and the read-write map and atomic instructions are delayed to ensure the lock-free reading RWMutex is used to separate and lock the read and write of map, so as to improve the read concurrency performanceĬompared with Mutex, it is suitable for the scene of more reading and less writing Mutex is used to realize the sequential access of multiple goroutine s to mapīoth reading and writing need Mutex lock and release lock, which is suitable for the scene with close reading to writing ratio Current map concurrent security solutions and problems Implementation mode
Set a struct, embed a read-write lock and a map.Ĥ. We must also think the same as the official, that is, lock. go officials gave a simple solution at that time. Most of the time, we will use mao objects concurrently, especially in a certain scale project, map will always save the data shared by goroutine. The concurrency problem of map is not so easy to find, and can be checked by -race.
#Gosync map code#
Source code will check whether there is concurrent write, delete the key, traversal when concurrent read and write problems. If this flag exists, a concurrency error will occur.Īfter setting, hashWriting will be reset. The reason is to check the hashWriting flag when reading. This is related to the source code of go. Finally, let's run the code and see the resultsįatal error: concurrent map read and map writeĪs a result, we expect that golang's build in map does not support concurrent read-write operations. The first goroutine is responsible for constantly reading the map object m, while the second goroutine is constantly writing the same data to the map object M. The meaning of the above code is also very easy to understand. Now, based on this scenario, build a sample code The official faq of golang has mentioned that the build in map is not thread(goroutine) safe. Therefore, the solution before go 1.9 is to bind an additional lock, encapsulate it into a new struct, or use the lock alone. Since go 1.6, concurrent reading and writing of maps will report errors, which exists in some well-known open source libraries. There was no problem with concurrent reading, and there might be problems with concurrent writing. Before Go 1.6, the built-in map type was partially goroutine safe.
0 kommentar(er)
