👨🏾‍💻 📁 🕒 Goで試してみましょう（context.Context） 🤹🏾 🖋️ 🤞🏽

こんにちは！

この記事では、独自のRWMutexを作成する方法を説明しますが、コンテキストをタイムアウトまたはトリガーしてロックをスキップする機能を備えています。つまり、TryLock（context.Context）とRTryLock（context.Context）を実装しますが、独自のMutex用です。

写真は、非常に狭い首に水を注ぐ方法を示しています。

まず、99％のタスクでは、このようなメソッドはまったく必要ないことを明確にする必要があります。ブロックされたリソースが長期間解放されない可能性がある場合に必要です。ブロックされたリソースが長時間ビジー状態のままである場合は、最初に、ブロック時間を最小限に抑えるようにロジックを最適化する必要があることに注意してください。

詳細については、例2の「Go」の「DancingwithMutexes」を参照してください。

しかし、それでも、1つのリソースフローを長期間保持する必要がある場合は、TryLockなしで実行するのは難しいように思われます。

, , atomic, . , . , , . , , .

Mutex:

// RWTMutex - Read Write and Try Mutex
type RWTMutex struct {
    state int32
    mx    sync.Mutex
    ch    chan struct{}
}

state — mutex, atomic.AddInt32, atomic.LoadInt32 atomic.CompareAndSwapInt32

ch — , .

mx — , , .

// TryLock - try locks mutex with context
func (m *RWTMutex) TryLock(ctx context.Context) bool {
    if atomic.CompareAndSwapInt32(&m.state, 0, -1) {
        return true
    }

    // Slow way
    return m.lockST(ctx)
}
// RTryLock - try read locks mutex with context
func (m *RWTMutex) RTryLock(ctx context.Context) bool {
    k := atomic.LoadInt32(&m.state)
    if k >= 0 && atomic.CompareAndSwapInt32(&m.state, k, k+1) {
        return true
    }

    // Slow way
    return m.rlockST(ctx)
}

ご覧のとおり、Mutexがロックされていない場合は単純にブロックできますが、ロックされていない場合は、より複雑なスキームに進みます。

最初に、チャネルを取得し、無限ループに入ります。ロックされていることが判明した場合は正常に終了し、そうでない場合は、2つのイベントのいずれか、チャネルのブロックが解除される、またはctx.Done（）ストリームのブロックが解除されるのを待ち始めます。

func (m *RWTMutex) chGet() chan struct{} {
    m.mx.Lock()
    if m.ch == nil {
        m.ch = make(chan struct{}, 1)
    }
    r := m.ch
    m.mx.Unlock()
    return r
}

func (m *RWTMutex) lockST(ctx context.Context) bool {
    ch := m.chGet()
    for {
        if atomic.CompareAndSwapInt32(&m.state, 0, -1) {
            return true
        }
        if ctx == nil {
            return false
        }
        select {
        case <-ch:
            ch = m.chGet()
        case <-ctx.Done():
            return false
        }
    }
}

func (m *RWTMutex) rlockST(ctx context.Context) bool {
    ch := m.chGet()
    var k int32
    for {
        k = atomic.LoadInt32(&m.state)
        if k >= 0 && atomic.CompareAndSwapInt32(&m.state, k, k+1) {
            return true
        }
        if ctx == nil {
            return false
        }
        select {
        case <-ch:
            ch = m.chGet()
        case <-ctx.Done():
            return false
        }
    }
}

ミューテックスのブロックを解除しましょう。

状態を変更し、必要に応じてチャネルのブロックを解除する必要があります。

上で書いたように、チャネルが閉じている場合、case <-chは実行フローをさらにスキップします。

func (m *RWTMutex) chClose() {
    if m.ch == nil {
        return
    }

    var o chan struct{}
    m.mx.Lock()
    if m.ch != nil {
        o = m.ch
        m.ch = nil
    }
    m.mx.Unlock()
    if o != nil {
        close(o)
    }
}
// Unlock - unlocks mutex
func (m *RWTMutex) Unlock() {
    if atomic.CompareAndSwapInt32(&m.state, -1, 0) {
        m.chClose()
        return
    }

    panic("RWTMutex: Unlock fail")
}
// RUnlock - unlocks mutex
func (m *RWTMutex) RUnlock() {
    i := atomic.AddInt32(&m.state, -1)
    if i > 0 {
        return
    } else if i == 0 {
        m.chClose()
        return
    }

    panic("RWTMutex: RUnlock fail")
}

ミューテックス自体の準備ができているので、いくつかのテストと、Lock（）やRLock（）などの標準メソッドを作成する必要があります。

私の車のベンチマークはこれらの速度を示しました

  
BenchmarkRWTMutexTryLockUnlock-8        92154297                12.8 ns/op             0 B/op          0 allocs/op
BenchmarkRWTMutexTryRLockRUnlock-8      64337136                18.4 ns/op             0 B/op          0 allocs/op

 RWMutex
BenchmarkRWMutexLockUnlock-8            44187962                25.8 ns/op             0 B/op          0 allocs/op
BenchmarkRWMutexRLockRUnlock-8          94655520                12.6 ns/op             0 B/op          0 allocs/op

 Mutex
BenchmarkMutexLockUnlock-8              94345815                12.7 ns/op             0 B/op          0 allocs/op

つまり、作業速度は通常のRWMutexおよびMutexに匹敵します。

githubのコード

RWTMutex

Goで試してみましょう（context.Context）

More articles: