How to lock a function or the body of a function from being called by two threads in golang?
My use case is that I have a webserver that is calling a serial interface which can only have one caller at a time, two calls will cancel each other out by creating noise for one another on the serial line.
Easiest way is to use sync.Mutex:
package main
import (
"fmt"
"sync"
"time"
)
var lock sync.Mutex
func main() {
go importantFunction("foo")
go importantFunction("bar")
time.Sleep(3 * time.Second)
}
func importantFunction(name string) {
lock.Lock()
defer lock.Unlock()
fmt.Println(name)
time.Sleep(1 * time.Second)
}
Here you'll see that "foo" and "bar" is printed one second apart even though they are go routines.
Go playground: https://play.golang.org/p/mXKl42zRW8
There are two approaches to implementing non-reentrant functions:
The two approaches have different merits:
Blocking non-reentrant functions are most easily implemented via mutex, as described in @Pylinux's answer.
Yielding non-reentrant functions can be implemented via atomic compare & swap, as follows:
import (
"sync/atomic"
"time"
)
func main() {
tick := time.Tick(time.Second)
var reentranceFlag int64
go func() {
for range tick {
go CheckSomeStatus()
go func() {
if atomic.CompareAndSwapInt64(&reentranceFlag, 0, 1) {
defer atomic.StoreInt64(&reentranceFlag, 0)
} else {
return
}
CheckAnotherStatus()
}()
}
}()
}
In the above, CheckAnotherStatus() is protected against re-entry such that the first caller sets reentranceFlag to 1, and subsequent callers fail to do the same, and quit.
Please consider my blog post, Implementing non re-entrant functions in Golang for a more elaborate discussion.
Pylinux's solution using a Mutex is, like he says, probably the simplest in your case. I'll add another one here as an alternative, though. It may or may not apply in your case.
Instead of using a Mutex, you could have a single goroutine perform all the operations on the serial interface, and use a channel to serialise the work it needs to perform. Example:
package main
import (
"fmt"
"sync"
)
// handleCommands will handle commands in a serialized fashion
func handleCommands(opChan <-chan string) {
for op := range opChan {
fmt.Printf("command: %s\n", op)
}
}
// produceCommands will generate multiple commands concurrently
func produceCommands(opChan chan<- string) {
var wg sync.WaitGroup
wg.Add(2)
go func() { opChan <- "cmd1"; wg.Done() }()
go func() { opChan <- "cmd2"; wg.Done() }()
wg.Wait()
close(opChan)
}
func main() {
var opChan = make(chan string)
go produceCommands(opChan)
handleCommands(opChan)
}
The advantage of this relative to a Mutex is that you have more control over the wait queue. With the Mutex, the queue exists implicitly at Lock(), and is unbounded. Using a channel, on the other hand, you can limit the maximum number of callers waiting and react appropriately if the synchronised call site is overloaded. You can also do things like checking how many goroutines are in the queue with len(opChan).
Edit to add:
A limitation with the above example (as noted in the comments) is that it doesn't handle returning results from the computation back to the original sender. One way to do that, while keeping the approach of using channels, is to introduce a result channel for each command. So instead of sending strings over the command channel, one can send structs of the following format:
type operation struct {
command string
result chan string
}
Commands would be enqueued onto the command channel as follows:
func enqueueCommand(opChan chan<- operation, cmd string) <-chan string {
var result = make(chan string)
opChan <- operation{command: cmd, result: result}
return result
}
This allows the command handler to send a value back to the originator of the command. Full example on the playground here.
main() should have close(opChan) at the end. It would then be better to remove the sleep and make the second goroutine not a new goroutine (i.e. part of main's instead). Then termination would happen cleanly. –
Iden close(opChan) at the end in its current state is racy and can theoretically lead to a panic, though. And putting the serialLoop() call in the main goroutine would prevent the program from exiting. I'll see if I can create a more complete example without hiding relevant parts in too much surrounding setup/teardown logic. –
Liebfraumilch close(opChan) not being able to be called with defer close(opChan). Doesn't defer work with waitGroup? –
Sundsvall defer close(opChan) as long as you know with certainty that wg.Wait() has run before it is called. Otherwise you might have producer goroutines still trying to write to the channel, which will lead to a panic if it is closed. So you haven't really added any safety unless you also handle Wait the same way. But then you also need to make sure there is an equal amount of Done calls to the total of the Add calls, or Wait will deadlock in the deferred call. So all-in-all, I'm not sure how much it will help you in terms of achieving code correctness. –
Liebfraumilch type Semafor struct {
sync.RWMutex
semafor int
}
var mySemafor *Semafor
func (m *Semafor) get() int { //read lock
if m != nil {
m.RLock()
defer m.RUnlock()
return m.semafor
} else {
panic ("Error : The semaphore is not initialized, IntSemafor()")
}
}
func (m *Semafor) set(val int) bool { //write lock
ok := false
if m != nil {
if val != 0 {
m.Lock()
if m.semafor == 0 {
m.semafor = val
ok = true
}
m.Unlock()
} else {
m.Lock()
m.semafor = val
ok = true
m.Unlock()
}
}
return ok
}
func InitSemafor() {
if mySemafor == nil {
mySemafor = &Semafor{}
mySemafor.set(0)
}
}
func OnSemafor() bool {
if mySemafor != nil {
for !mySemafor.set(1) {
for mySemafor.get() == 1 {
SleepM(2)
}
}
return true
} else {
panic("Error : The semaphore is not initialized, InitSemafor()")
}
}
func OffSemafor() {
mySemafor.set(0)
}
© 2022 - 2024 — McMap. All rights reserved.
defer lock.Unlock()just afterlock.Lock()might be preferable, just in case anything inside the logic ofimportantFunctionpanics. That way theUnlockcall is guaranteed to happen. – Liebfraumilch