Go Basic: Understanding Atomic, Mutex, Stateful Goroutines in Go

golang 12 minutes read (About 1863 words)

Learning about synchronization and state management in concurrent programming.

full lessons here👇:
https://programmerscareer.com/golang-basic-skill/

Generated by AI, there may be errors, for reference only

Topic: Atomic, Mutexes, Stateful Goroutines

To begin with, let’s set the context straight and understand these concepts:

1. Atomics:
Atomics in Go are part of the “sync/atomic” package. They provide low-level locking mechanisms used for synchronisation. For instance, these atomic functions can help to add, compare or load integers or pointers in a concurrent-safe way, ensuring that the operation is completed as a single uninterrupted task.

2. Mutexes:
Mutex stands for “Mutual Exclusion”. A mutex is like a token which can be held by a single goroutine at any point in time. If other goroutines try to acquire the mutex, they will be blocked until the goroutine that’s currently holding the mutex releases it. This is a critical tool for controlling access to a segment of code that cannot safely be executed concurrently.

3. Stateful Goroutines:
Stateful Goroutines are goroutines that maintain their own private state. Instead of sharing variables between goroutines and synchronising access using locks (like Atomics or Mutexes), each goroutine is responsible for managing its own state, and other goroutines interact with it by sending and receiving messages on channels.

Let’s take an example for better understanding:

Imagine we have multiple goroutines who all want to increment a counter. A traditional way to handle this situation would be to use a mutex to ensure safe access to the shared ‘counter’ variable.

1
2
3
4
5
6
7
8
9
10
11
var (  
    mutex sync.Mutex  
    counter int  
)  

func worker() {  
    // Lock so only one goroutine at a time can access the counter  
    mutex.Lock()  
    counter++  
    mutex.Unlock()  
}

In the above example, the worker goroutines lock the mutex to ensure exclusive access to the counter. Once the operation of incrementing the counter is finished, the worker unlocks the mutex.

Now, let’s see how we could re-implement this example using stateful goroutines:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func main() {  
    // Create a channel for sending increments requests to the goroutine  
    incrementer := make(chan bool)  
    // The stateful goroutine  
    go func() {  
        var counter int  
        for range incrementer {  
            counter++  
            fmt.Println(counter)  
        }  
    }()  
    // Send 10 increment requests and then close the channel  
    for i := 0; i < 10; i++ {  
        incrementer <- true  
    }  
    close(incrementer)  
}

In this example, each increment request results in a message sent on the incrementer channel. The Stateful Goroutine receives these requests and handles them in isolation, ensuring the state (the counter) is safely incremented.

These are just for starter. Both Atomics and Mutexes have a much deeper level of complexity and use cases along with Stateful Goroutines.

Topic: Introduction to the ‘sync/atomic’ package

Go’s sync/atomic package provides low-level atomic memory primitives useful for implementing synchronization algorithms.

Consider a scenario where multiple goroutines are reading and writing to a shared variable, this could lead to what’s called a data race, where the outcome depends on the sequence of execution.

Let’s understand this with a simple code example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
package main  

import (  
    "fmt"  
    "sync"  
)  

var (  
    counter int64  
    wg sync.WaitGroup  
)  

func main() {  
    wg.Add(2)  

    go incCounter(1)  
    go incCounter(2)  
    wg.Wait()  
    fmt.Println("Final Counter:", counter)  

}  

func incCounter(id int) {  
    defer wg.Done()  

    for count := 0; count < 2; count++ {  
        value := counter  
        value++  
        counter = value  
    }  

}

In this program, we are starting two goroutines to increment the counter twice, once for each goroutine. The final value of the counter, however, is 2 and not 4. This is because of data race. To avoid this kind of scenario, we would use atomic functions. Here’s how to do it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package main  

import (  
    "fmt"  
    "sync"  
    "sync/atomic"  
)  

var (  
    counter int64  
    wg sync.WaitGroup  
)  

func main() {  
    wg.Add(2)  
    go incCounter(1)  
    go incCounter(2)  

    wg.Wait()  
    fmt.Println("Final Counter:", counter)  

}  

func incCounter(id int) {  
    defer wg.Done()  
    for count := 0; count < 2; count++ {  
        atomic.AddInt64(&counter, 1)  
    }  
}

By using sync/atomic package, we ensure that only one goroutine plays with the counter at a time.

Topic: Introduction to Mutexes

Let’s consider a similar situation but with a map:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package main  

import (  
    "fmt"  
    "sync"  
)  

var (  
    sharedRsc = make(map[string]string)  
)  

func main() {  
    var wg sync.WaitGroup  
    wg.Add(1)  
    go func() {  
        defer wg.Done()  
        sharedRsc["one"] = "first value"  
    }()  
    go func() {  
        sharedRsc["two"] = "second value"  
    }()  
    wg.Wait()  
    fmt.Println(sharedRsc)  
}

This program too has a data race condition. The map type in Go doesn’t support concurrent reads and writes. A Mutex is used to provide a locking mechanism to ensure that only one Goroutine is running the critical section of code at any point of time to prevent race condition from happening. Mutex is available in the sync package and provides Lock and Unlock method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package main  

import (  
    "fmt"  
    "sync"  
)  

var (  
    mutex sync.Mutex  
    sharedRsc = make(map[string]string)  
)  

func main() {  
    var wg sync.WaitGroup  
    wg.Add(1)  
    go func() {  
        defer wg.Done()  
        mutex.Lock()  
        sharedRsc["one"] = "first value"  
        mutex.Unlock()  
    }()  
    go func() {  
        mutex.Lock()  
        sharedRsc["two"] = "second value"  
        mutex.Unlock()  
    }()  
    wg.Wait()  
    fmt.Println(sharedRsc)  
}

Now, the sharedRsc can be safely accessed by multiple goroutines.

Topic: Using Mutexes to Protect Shared State

In this section, I’d like to ask you to try and create a short program which protects a shared state using a mutex. This could be a counter or any other variable which might be subject to a data race condition. This exercise should help consolidate your understanding of mutexes.

Bear in mind, these are the very basics of Atomics, Mutexes and Go Concurrency. We will soon touch upon the advanced aspects.

let’s take a further step and explore Stateful Goroutines.

Topic: Understanding Stateful Goroutines

As I briefly touched upon before, stateful goroutines are a different approach to dealing with shared state in concurrent code. The idea here is to encapsulate the state within a goroutine and only expose operations on that state through communication channels.

This approach can make it simpler to reason about the concurrency in your code because the consistent state is only altered in a single, welldefined, location.

Here’s an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
package main  

import (  
    "fmt"  
    "math/rand"  
    "sync"  
    "time"  
)  

type Counter struct {  
    value int  
    o sync.Mutex  
}  

func (c *Counter) Increment() {  
    c.o.Lock()  
    c.value++  
    c.o.Unlock()  
}  

func (c *Counter) Read() int {  
    c.o.Lock()  
    defer c.o.Unlock()  
    return c.value  
}  

type Job struct {  
    delay time.Duration  
    name string  
    value int  
}  

func worker(id int, jobs <-chan Job, c *Counter) {  
    for j := range jobs {  
        fmt.Println("worker", id, "started job", j.name)  
        time.Sleep(j.delay)  
        fmt.Println("worker", id, "finished job", j.name)  
        c.Increment()  
    }  
}  

func main() {  
    const numJobs = 5  
    jobs := make(chan Job, numJobs)  
    counter := Counter{}  
    var wg sync.WaitGroup  
    for w := 1; w <= 3; w++ {  
        wg.Add(1)  
        go func(id int) {  
            defer wg.Done()  
            worker(id, jobs, &counter)  
        }(w)  
    }  
    for j := 1; j <= numJobs; j++ {  
        jobs <- Job{time.Millisecond * time.Duration(rand.Intn(100)), fmt.Sprintf("job%d", j), j}  
    }  
    close(jobs)  
    wg.Wait()  

    fmt.Println("counter:", counter.Read())  

}

In this code the Counter struct encapsulates an integer value and embeds a sync.Mutex to control access to this value. The Increment and Read methods on the Counter struct both use this mutex to control concurrent access to the value field.

Workers are represented by goroutines which receive jobs from a channel and increment the counter after each one. Because the state of the counter is completely encapsulated and only accessible through two methods, which are both safe for concurrent use, we know that our increment operation is atomic.

Topic: case study

Case Study 1: Basic Counter Server

Let’s take a look at an example where understanding of Atomics, Mutexes and Stateful Goroutines comes into picture. We are going to develop a basic counter server:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package main  

import (  
    "fmt"  
    "net/http"  
    "sync"  
)  

var (  
    counter int  
    mutex = &sync.Mutex{}  
)  

func echo(w http.ResponseWriter, r *http.Request) {  
    mutex.Lock()  
    counter++  
    fmt.Fprintf(w, "Counter: %d\n", counter)  
    mutex.Unlock()  
}  

func main() {  
    http.HandleFunc("/", echo)  
    http.ListenAndServe(":8080", nil)  
}

In this example, we have a simple web server that increments a counter every time it gets a hit. We use a mutex to make sure that only one goroutine gets to increment the counter at a time. This way, we ensure that the counter always reflects the correct number of hits, even under heavy load.

Case Study 2: Cache Implemented with Mutex and Map

Consider you have a cache where you store key-value pairs and you’ve used Go’s map:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
type Cache struct {  
    cache map[string]string  
    mux sync.Mutex  
}  

func NewCache() *Cache {  
    return &Cache{  
        cache: make(map[string]string),  
        mux: sync.Mutex{},  
    }  
}  

func (c *Cache) Set(key string, value string) {  
    c.mux.Lock()  
    defer c.mux.Unlock()  
    c.cache[key] = value  
}  

func (c *Cache) Get(key string) (string, bool) {  
    c.mux.Lock()  
    defer c.mux.Unlock()  
    val, found := c.cache[key]  
    return val, found  
}

Here, you’re using a map to store your cache and Mutexes to make sure that only one goroutine at a time can access a value in the cache.

These case studies are designed to give you a basic understanding of how these sync primitives can be applied to solve real-world problems. As you can see, both Atomics and Mutexes have their own use cases. While Atomics are great for ensuring that only one goroutine can execute a particular section of code at a time, Mutexes bring a big savior to the tables where shared state is used and we want to avoid data race conditions.

I hope these case studies help you understand these concepts better. Can we move forward or do you have anything in mind that you would like to ask about?

Topic: Review and Assessments

To consolidate your understanding, let’s take a moment to review the key points covered.

  1. Atomic Variables: Go’s sync/atomic package provides low-level atomic memory primitives that can be used to implement synchronization algorithms and data structures in a multithreaded environment.
  2. Mutexes: A Mutex is a mutual exclusion primitive that can be used to protect shared resources from concurrent access.
  3. Stateful Goroutines: Goroutines with a state encapsulated within themselves, only exposing operations on that state through communication channels.

Now, to truly grasp these concepts, let’s put your understanding to test. If you could, please verbally walk me through the following scenario:

Imagine you have to develop a server application which takes in numerical inputs from multiple clients simultaneously, and maintains a running total. Conceptually, what Go concurrency mechanism(s) would you utilize to ensure that the running total is always accurate, despite the simultaneous multiple client inputs?

Remember, there are no right or wrong answers and it’s perfectly fine if you don’t arrive at a solution immediately. The objective here is to apply your learning and understanding of the concepts!

中文文章: https://programmerscareer.com/zh-cn/go-basic-06/
Author: Wesley Wei – Twitter Wesley Wei – Medium
Note: If you choose to repost or use this article, please cite the original source.

wechat
Wechat(微信公众号)
x
#code
Go basic: Understanding Timers, Tickers, Worker Pools, Waitgroups, Rate Limiting in Go Go Basic: Understanding Error Handling: Errors, Panic, Defer, Recover in Go

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×