3 ms·
It could just be one map shared by many goroutines, which normally causes a panic: fatal error: concurrent map writes
by artursapek 9y ago
It could just be one map shared by many goroutines, which normally causes a panic:
fatal error: concurrent map writes
- freecodyx 9y agoi am dealing with this problem right now. also i have a big problem with deepclone, I did a big rewrite of a current project, and clearly it was badly designed :(
- deleted 9y ago[deleted]
- azinman2 9y agoStandard practice is to use a mutex to guard against concurrent usage.
- logicallee 9y agoalso necessary for reads? Also, do you have any good references to proper best practices around concurrent and parallel programming? (in Go.) Like just basic things. Code I can copy and paste without it having obscure race conditions because that use of mutex is absolutely correct, and something that lets me understand the limitations. I feel like it is very easy to do things "wrong" or not notice some edge cases. In C++ I didn't only ever coded single-threaded for this reason. Too many gotchas. Any help would be appreciated.
- carbocation 9y agoNecessary for reads unless no additional writing will be done. If you initialize/write into a map and then later have concurrent reads from it, the program will run. If you try to write in the midst of this, it will crash.
- dgellow 9y agoI would suggest you to read the book "Concurrency in Go", by Katherine Cox-Budai, 2017: http://shop.oreilly.com/product/0636920046189.do http://shop.oreilly.com/product/0636920046189.do
- logicallee 9y agoThank you for the recommendation!