On Wed, Jan 13, 2021 at 8:31 PM Robert Engels wrote:
> I forgot. But it’s to important to mention that different synchronization
> methods perform differently under contention so what works well for 2 might
> be really poor with 64.
>
Yes, but the ratio of reads to writes is usually more importa
I forgot. But it’s to important to mention that different synchronization
methods perform differently under contention so what works well for 2 might be
really poor with 64.
> On Jan 13, 2021, at 10:04 PM, Kurtis Rader wrote:
>
>
>> On Wed, Jan 13, 2021 at 7:58 PM Robert Engels wrote:
>
>
On Wed, Jan 13, 2021 at 7:58 PM Robert Engels wrote:
> Why limit yourself to two? Use N routines and have each process every N in
> the list.
>
You missed this statement in the original message of this thread:
So the sketch of the go implementation is that I would have three threads
- main, t0
Why limit yourself to two? Use N routines and have each process every N in the
list.
> On Jan 13, 2021, at 7:25 PM, Nikolay Dubina
> wrote:
>
>
> Any primitive in `sync` package will do. I would go for two `RWMutex` each
> for each goroutine, or two unbuffered channels for each gorouitne.
Any primitive in `sync` package will do. I would go for two `RWMutex` each
for each goroutine, or two unbuffered channels for each gorouitne. However,
AFAIK, in Go you can't force start execution of a goroutine. Go will try to
wake up any unblocked goroutine as soon as possible though.
On Thursd