3 ms·

> 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

> 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.

littlestymaar 7y ago
When you have 2 threads running in parallel and the outcome of the computation depends on the order in which they do their job first, that's a race condition.
therealdrag0 7y ago
I haven't really read it but I'll take a stab (with psuedo code). I think NextIndex() is incrementing s.current and modding it with servers.length. 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.
- westoque 7y ago
  Thanks for the explanation. Forgive my lack of knowledge, but can it not be solved by using parallelism instead of concurrency/threads? I thought Go has first class primitives to be able to do this?
  - therealdrag0 7y ago
    > parallelism instead of concurrency/threads. 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." https://golang.org/pkg/sync/atomic/ https://golang.org/pkg/sync/atomic/
    - westoque 7y ago
      > What do you mean? These seem synonymous to me. What I meant was similar to this talk: https://blog.golang.org/concurrency-is-not-parallelism 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)
      - biggestdecision 7y ago
        Channels aren't a way to avoid mutexes/locking, they are just meant to be simpler to write & reason about. Channels are implemented using mutexes under the hood.
- biggestdecision 7y ago
  An increment like s.current++ isn't atomic either. If two threads increment simultaneously the value may only increase by 1.

littlestymaar 7y ago

When you have 2 threads running in parallel and the outcome of the computation depends on the order in which they do their job first, that's a race condition.

therealdrag0 7y ago

I haven't really read it but I'll take a stab (with psuedo code). I think NextIndex() is incrementing s.current and modding it with servers.length. 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.

westoque 7y ago
Thanks for the explanation. Forgive my lack of knowledge, but can it not be solved by using parallelism instead of concurrency/threads? I thought Go has first class primitives to be able to do this?
- therealdrag0 7y ago
  > parallelism instead of concurrency/threads. 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." https://golang.org/pkg/sync/atomic/ https://golang.org/pkg/sync/atomic/
  - westoque 7y ago
    > What do you mean? These seem synonymous to me. What I meant was similar to this talk: https://blog.golang.org/concurrency-is-not-parallelism 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)
    - biggestdecision 7y ago
      Channels aren't a way to avoid mutexes/locking, they are just meant to be simpler to write & reason about. Channels are implemented using mutexes under the hood.
biggestdecision 7y ago
An increment like s.current++ isn't atomic either. If two threads increment simultaneously the value may only increase by 1.