<p>Currently, I am performing a hill climbing algorithm to reach a desired state. Each iteration, an evaluation of the best move to perform is carried out by trying out each move on the current state and comparing the resultant states.</p>
<p>This evaluation seems parallelisable. However, since the state is large, creating new goroutines every iteration and communicating the state to each of them might incur significant overhead. If that is the case, I am wondering if it makes sense to instead initialise a set number of goroutines, communicate the initial state to them once, keep them open and then communicate the actual move made (small in size) to each goroutine every iteration to reduce communication overhead.</p>
<p>I'm new to Go, so I'm not sure whether this approach makes sense. Comments and feedback would be appreciated!</p>
<hr/>**评论：**<br/><br/>Nooby1990: <pre><p>In go sharing state by communication is preferred by many, but that does not mean that it is always the best solution. If the state is Big it could make sense to share a Pointer to this state and then relying on Mutex for locking. Look at what the sync and sync.Atomic Packages provides. It could be helpful.</p>
<p>For your second idea (keeping the go routines open and communicating moves): That is easily doable. Just have your go routines read the moves from a Channel (one channel for each routine) and write the results to a different channel (only one channel).</p>
<pre><code>func routine(initialState WorldState, moves chan MoveType, results chan ResultType) {
for _, v := range moves {
// Evaluate move here
results <- result
}
}
</code></pre>
<p>You would also need a Go Routine that reads the results channel and supplies the Moves to the moves channels on each iteration. It could also be helpful to have a WaitGroup to signal that all the results of this iteration are written to the results channel and that the next iteration could start.</p></pre>Numiro: <pre><p>What you're looking for is master slave thread pooling, in most other languages, in go I think they might be called factories or something, there should be a default pooling utility in there somewhere.</p></pre>PsyWolf: <pre><p>So it's hard to give suggestions without knowing exactly what you're doing, but I would think that you could design your state such that all of your goroutines could read from that shared state as long as they send messages to a single writer goroutines to update it. If you used an event source like model where your shared state is an initial state and a slice of actions that have happened in order, then your goroutines can find and apply new actions on each iteration.</p>
<p>This assumes that the writing goroutine can figure out which order actions should ultimately be applied in.</p></pre>
