CODEWITHSUNDEEP
golockingmutex
Francesco
Francesco

Reputation: 511

Getting confused on Locks/Mutex in Go

I am trying to build a map. Normally all read can be done in parallel, except when a write comes, than all reads need to be locked. I thought I understood how Mutex work in go but clearly I do not.

I first tried to use a RWMutex write lock:

type person struct {
    sync.RWMutex
    age int
}

func main() {
    a := person{age: 3}
    fmt.Println(a.age)
    go func() {
        a.Lock()
        time.Sleep(5 * time.Second)
        a.age = 4
        fmt.Println(a.age)
        a.Unlock()
    }()
    fmt.Println(a.age)
    fmt.Println("main", a.age)
    time.Sleep(20 * time.Second)
}

I somewhat expected that the wrote lock would lock the read operation a.age. Instead I got:

3
3
main 3
4

So I decided to add also a read lock:

func main() {
    a := person{age: 3}
    fmt.Println(a.age)
    go func() {
        a.Lock()
        a.RLock()
        time.Sleep(5 * time.Second)
        a.age = 4
        fmt.Println(a.age)
        a.Unlock()
        a.RUnlock()
    }()
    fmt.Println(a.age)
    fmt.Println("main", a.age)
    time.Sleep(20 * time.Second)
}

Even worse, I got:

3
3
main 3

Clearly I am not understanding how this works. Thanks for any help.

Upvotes: 1

Views: 2953

Answers (2)

dm03514
dm03514

Reputation: 55972

type person struct {
    sync.RWMutex
    age int
}

func main() {
    a := person{age: 3}
    fmt.Println(a.age)
    go func() {
        a.Lock()
        time.Sleep(5 * time.Second)
        a.age = 4
        fmt.Println(a.age)
        a.Unlock()
    }()
    fmt.Println(a.age)
    fmt.Println("main", a.age)
    time.Sleep(20 * time.Second)
}


3 <- 2nd line of `main` fmt.Println(a.age) 
3 <- after go routine fmt.Println(a.age)
main 3 <- fmt.Println("main", a.age)
4 <- goroutine after sleep fmt.Println(a.age)

The write lock does not lock the variable and could result in a race condition. (https://blog.golang.org/race-detector)

Locks will only synchronize access to a.age, making write access exclusive to a single goroutine at a single time. It DOES not synchronize your go routines, which will need some sort of additional synchronization. one of the most common pattern for synchronize the two would be to use a wait group:

https://golang.org/pkg/sync/#WaitGroup

 func main() {
        var wg sync.WaitGroup
        wg.Add(1)
        a := person{age: 3}
        fmt.Println(a.age)
        go func() {
            defer wg.Done()
            a.Lock()
            time.Sleep(5 * time.Second)
            a.age = 4
            fmt.Println(a.age)
            a.Unlock()
        }()
        wg.Wait()
        fmt.Println(a.age)
    }

The wait group synchronizes the two goroutines ensuring that the last print will be 4

Upvotes: 0

Adrian
Adrian

Reputation: 46592

Never double-lock. Your issue is that you're not wrapping the reads at the end of main in locks - if they don't try to establish a lock, there is nothing to prevent them reading while something else writes (even if the write is using a lock). The lock itself is what provides mutual exclusion (MutEx), so you only get it if you use it consistently:

func main() {
    a := person{age: 3}
    fmt.Println(a.age)
    go func() {
        a.Lock()
        time.Sleep(5 * time.Second)
        a.age = 4
        fmt.Println(a.age)
        a.Unlock()
    }()
    a.RLock()
    fmt.Println(a.age)
    fmt.Println("main", a.age)
    a.RUnlock()
    time.Sleep(20 * time.Second)
}

There is no magic happening here; it's actually the calls to Lock and RLock that do the locking. If you don't call them, nothing prevents concurrent accesses. When you call Lock, it waits until it can get the lock all to itself, then it locks it and returns. When you call RLock, it waits until there are no write locks, then grabs a (shared) read lock. It is calling those functions which provides mutual exclusion, not any magic happening behind the scenes.

Upvotes: 1

Related Questions