Is there a way to model shared state using messages?

Question

So currently I've come upon a very real problem in writing "correct" golang. I have an object (for the sake of simplicity lets think of it as a map[string]string) and I want it to hold a "shared" state between multiple gortuines.

Currently the implementation goes something like this:

//Inside shared_state.go

var sharedMap    map[string]string = make(map[string]string)
var mutex       sync.RWMutex     = sync.RWMutex{}

func Add(k string, v string) bool {
    mutex.Lock()
    if _, exists := sharedMap[k]; exists {
        mutex.Unlock()
        return false
    }
    tokenMap[k] = v
    mutex.Unlock()
    return true
}
//Other methods to access, modify... etc

Whilst this does do the job is quite an ugly implementation by go standards, which encourage modeling concurrency using message.

Are there easy ways of modeling shared state using messages that I am blatantly unaware of ? Or am I forced to use mutexes in this kind of cases ?

Answer 1

You don't "model shared state using messages", you use messages instead of shared state, which requires designing the application based on different fundamentals. It is generally not a matter of rewriting a mutex as a channel, but a completely different implementation approach, and that approach won't be applicable to all scenarios where you need to synchronize operations. If a shared map is the best approach for your situation, then a mutex is the correct way to synchronize access to it.

As an example from my own experience, I've developed applications that allow for changing their configuration at runtime. Rather than having a shared Config object and synchronizing access to it, I give each main goroutine a channel on which it can receive configuration updates. When the config changes, the update is sent to all the listeners. When a listener gets a config change, it can complete its current operation, then deal with the config change in whatever way is appropriate to that routine - it may just update its local copy of the config, it may close connections to external resources and open new ones, etc. Instead of sharing data, I'm sending and receiving events, which is a fundamentally different design.