On Wednesday, 23 February 2022 at 03:39:45 UTC [email protected] wrote: > I have also checked the sync.Map and it seems to allow spontaneous reading > but still prohibits spontaneous writing. >
I'm not sure what you mean by that. Do you really mean "spontaneous" or "simultaneous"? sync.Map serializes reads and writes to the map. If two goroutines try to update the map simultaneously, the updates will happen safely, one after the other. It doesn't prohibit spontaneous writes, only ensures that one is delayed until the other is complete. More importantly, sync.Map doesn't synchronize anything else. So if map["foo"] contains a pointer to some struct Bar, and two goroutines both try to access the same Bar, they will conflict with each other. It's a fundamental issue here that a consumer could request the current quotation for stock X at the same instant as a new update can come in for stock X asynchronously. You are going to have to serialize this one way or another so that the consumer reading the current quotation is guaranteed to see it how it was either before *or* after the update, not during. I'd say you need to rethink your concurrency approach. My first reaction is to have a separate goroutine which maintains all the current quotations, and has a channel which accepts messages saying "update quotation" or "read quotation". The "read quotation" message can include a response channel as one of its members. If you still feel you want to go down the mutex locking approach, then at least first watch and digest this video, "Rethinking Classical Concurrency Patterns" by Bryan C Mills: https://www.youtube.com/watch?v=5zXAHh5tJqQ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b7f81fbc-980e-42b7-9c48-06e12d498a7an%40googlegroups.com.
