> Multiple clients will connect to the load balancer and when each of them requests a next peer to pass the traffic on race conditions could occur.
I quite don't understand what this means? What race conditions? Can anybody explain? Thanks.
I quite don't understand what this means? What race conditions? Can anybody explain? Thanks.
To do this, there are three operations, SET s.current to +1, and GET s.current so that it can be MODDED with servers.length.
If that SET and GET are not coordinated between threads, then a race could sour the index. For example, if two threads call this method at the same time, they could both SET the +1 before either GETs the value, then they will both get the same value +2 from where it started instead of +1 for each caller.
What do you mean? These seem synonymous to me.
> I thought Go has first class primitives to be able to do this?
TBH I'm only 1 week into learning Go myself (coming from Java/Scala/JS/etc). But it looks like the article used what Go offers. They used the atomic package which says, "provides low-level atomic memory primitives useful for implementing synchronization algorithms."
What I meant was similar to this talk: https://blog.golang.org/concurrency-is-not-parallelism where there is also a load balancer example around 20:20 and using go channels (the primitive I’m pertaining to)