gorex

`gorex == GORoutine mutual EXclusion`

This package implements Mutex and RWMutex. They are similar to sync.Mutex and sync.RWMutex, but
they track which goroutine locked the mutex and will not cause a deadlock if
the same goroutine will try to lock the same mutex again.

type myEntity struct {
    gorex.Mutex
}
func (ent *myEntity) func1() {
    ent.Lock()
    defer ent.Unlock()
    .. some stuff ..
    ent.func2() // will not get a deadlock here!
    .. other stuff ..
}
func (ent *myEntity) func2() {
    ent.Lock()
    defer ent.Unlock()
    .. more stuff ..
}

The same in other syntax:

type myEntity struct {
    gorex.Mutex
}
func (ent *myEntity) func1() {
    ent.LockDo(func() {
        .. some stuff ..
        ent.func2() // will not get a deadlock here!
        .. other stuff ..
    })
}
func (ent *myEntity) func2() {
    ent.LockDo(func(){
        .. more stuff ..
    })
}

locker := &goroutine.RWMutex{}
locker.RLockDo(func() {
    .. do some read-only stuff ..
    if cond {
      return
    }
    locker.LockDo(func() { // will not get a deadlock here!
        .. do write stuff ..
    })
})

But…

But you still will get a deadlock if you do this way:

var locker = &gorex.RWMutex{}
func someFunc() {
    locker.RLockDo(func() {
        .. do some read-only stuff ..
        if cond {
          return
        }
        locker.LockDo(func() { // you will get a deadlock here!
            .. do write stuff ..
        })
    })
}()
func main() {
    go someFunc()
    go someFunc()
}

because there could be a situation that a resource is blocked by a RLockDo from
both goroutines and both goroutines waits (on LockDo) until other goroutine
will finish RLockDo. But still you will easily see the reason of deadlocks due
to LockDo-s in the call stack trace.

Benchmark

It’s essentially slower than bare sync.Mutex/sync.RWMutex:

goos: linux
goarch: amd64
pkg: github.com/xaionaro-go/gorex
Benchmark/Lock-Unlock/single/sync.Mutex-8             77933413            15.2 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-Unlock/single/sync.RWMutex-8           46052574            26.1 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-Unlock/single/Mutex-8                  20281420            58.6 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-Unlock/single/RWMutex-8                13518639            87.1 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-Unlock/parallel/sync.Mutex-8           10836991           111 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-Unlock/parallel/sync.RWMutex-8          9065725           133 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-Unlock/parallel/Mutex-8                 9425310           123 ns/op           2 B/op           0 allocs/op
Benchmark/Lock-Unlock/parallel/RWMutex-8               5309696           213 ns/op           4 B/op           0 allocs/op
Benchmark/RLock-RUnlock/single/sync.RWMutex-8         76609815            15.2 ns/op           0 B/op           0 allocs/op
Benchmark/RLock-RUnlock/single/RWMutex-8              25071478            47.9 ns/op           0 B/op           0 allocs/op
Benchmark/RLock-RUnlock/parallel/sync.RWMutex-8       25705654            48.3 ns/op           0 B/op           0 allocs/op
Benchmark/RLock-RUnlock/parallel/RWMutex-8            14786738            80.9 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-ed:Lock-Unlock/single/Mutex-8          31392260            38.2 ns/op           0 B/op           0 allocs/op
Benchmark/Lock-ed:Lock-Unlock/single/RWMutex-8        32588916            37.6 ns/op           0 B/op           0 allocs/op
Benchmark/RLock-ed:RLock-RUnlock/single/RWMutex-8     26416754            46.1 ns/op           0 B/op           0 allocs/op
Benchmark/RLock-ed:RLock-RUnlock/parallel/RWMutex-8             13113901            88.7 ns/op           0 B/op           0 allocs/op
PASS
ok      github.com/xaionaro-go/gorex    20.321s

But sometimes it allows you to think more about strategic problems
(“this stuff should be edited atomically, so I’ll be able to…”)
instead of wasting time on tactical problems (“how to handle those locks”) :)

If you still have a Deadlock…

Of course this package does not solve all possible reasons of deadlocks,
but it also provides a way to debug what’s going on. First of all,
I recommend you to use LockDo instead of bare Lock when possible:

It will make sure you haven’t forgot to unlock the mutex.
It will be shown in the call stack trace (so you’ll see what’s going on).

If you already have a problem with a deadlock, then I recommend you to write
and unit/integration test which can reproduce the deadlock situation and then
limit by time gorex.DefaultInfiniteContext.
On a deadlock it will panic and will show the call stack trace of every routine
which holds the lock.

For example in my case I saw:

monopolized by:
/home/xaionaro/.gimme/versions/go1.13.linux.amd64/src/runtime/proc.go:2664 (runtime.goexit1)
panic: The InfiniteContext is done...

So it seems a routine already exited (and never released the lock). So a support
of the build tag deadlockdebug was added, which will print a call
stack trace of a lock which was never released (and goroutine already exited). Specifically
in my case it printed:

$ go test ./... -timeout 1s -bench=. -benchtime=100ms -tags deadlockdebug
...
an opened lock {LockerPtr:824636154976 IsWrite:true} which was never released (and the goroutine already exited):
/home/xaionaro/go/pkg/mod/github.com/xaionaro-go/gorex@v0.0.0-20200308222358-b650fa4b5b14/rw_mutex.go:72 (github.com/xaionaro-go/gorex.(*RWMutex).lock)
/home/xaionaro/go/pkg/mod/github.com/xaionaro-go/gorex@v0.0.0-20200308222358-b650fa4b5b14/rw_mutex.go:43 (github.com/xaionaro-go/gorex.(*RWMutex).Lock)
/home/xaionaro/go/src/github.com/xaionaro-go/secureio/session.go:1480 (github.com/xaionaro-go/secureio.(*Session).sendDelayedNow)
/home/xaionaro/go/src/github.com/xaionaro-go/secureio/session.go:1774 (github.com/xaionaro-go/secureio.(*Session).startKeyExchange.func2)
/home/xaionaro/go/src/github.com/xaionaro-go/secureio/key_exchanger.go:449 (github.com/xaionaro-go/secureio.(*keyExchanger).sendSuccessNotifications)
/home/xaionaro/go/src/github.com/xaionaro-go/secureio/key_exchanger.go:408 (github.com/xaionaro-go/secureio.(*keyExchanger).Handle.func2)
/home/xaionaro/go/src/github.com/xaionaro-go/secureio/key_exchanger.go:242 (github.com/xaionaro-go/secureio.(*keyExchanger).LockDo)
...

So I opened line session.go:1480 added defer sess.delayedWriteBuf.Unlock() and it fixed the problem :)

Comparison with other implementations

I found 2 other implementations:

The first one is broken:

panic: unsupported go version go1.13

The second one sleeps in terms of millisecond, which:

Give good result if the lock is short-living: performance is much better (than here).
Continuously consumes CPU resources on long-living locks, while I’m developing an application for mobile phones and would like to avoid such problems.
Does not support RLock/RUnlock.