活锁是正在主动执行并发操作的程序,但这些操作无法向前移动程序的状态。

你有没有在走廊走向另一个人? 她移动到一边让你通过,但你也是这样做的。 所以你转移到另一边,但她也是这样做的。 想象这会永远持续下去,这就是活锁。

接下来的这个例子,我不建议试图了解它的细节,直到你牢牢掌握sync包。 相反,我建议遵循代码标注来理解高亮,然后将注意力转移到包含示例核心的第二个代码块。

cadence := sync.NewCond(&sync.Mutex{})
go func() {
    for range time.Tick(1 * time.Millisecond) {

        cadence.Broadcast()
    }
}()

takeStep := func() {
    cadence.L.Lock()
    cadence.Wait()
    cadence.L.Unlock()
}

tryDir := func(dirName string, dir *int32, out *bytes.Buffer) bool { //1
    fmt.Fprintf(out, " %v", dirName)
    atomic.AddInt32(dir, 1) //2
    takeStep()              //3
    if atomic.LoadInt32(dir) == 1 {
        fmt.Fprint(out, ". Success!")
        return true
    }
    takeStep()
    atomic.AddInt32(dir, -1) //4
    return false
}

var left, right int32
tryLeft := func(out *bytes.Buffer) bool { return tryDir("left", &left, out) }
tryRight := func(out *bytes.Buffer) bool { return tryDir("right", &right, out) }
  1. tryDir 允许一个人尝试向某个方向移动并返回,无论他们是否成功。 每个方向都表示为试图朝这个方向移动的次数。
  2. 首先,我们通过将该方向递增1来朝着某个方向移动。 我们将在第3章详细讨论atomic包。现在,你只需要知道这个包的操作是原子操作。
  3. 每个人必须以相同的速度或节奏移动。 takeStep模拟所有动作之间的恒定节奏。
  4. 在这里,这个人意识到他们不能在这个方向上放弃。 我们通过将该方向递减1来表示这一点。
walk := func(walking *sync.WaitGroup, name string) {
    var out bytes.Buffer
    defer func() { fmt.Println(out.String()) }()
    defer walking.Done()
    fmt.Fprintf(&out, "%v is trying to scoot:", name)
    for i := 0; i < 5; i++ { //1
        if tryLeft(&out) || tryRight(&out) { //2
            return
        }
    }
    fmt.Fprintf(&out, "\n%v tosses her hands up in exasperation!", name)
}

var peopleInHallway sync.WaitGroup //3
peopleInHallway.Add(2)
go walk(&peopleInHallway, "Alice")
go walk(&peopleInHallway, "Barbara")
peopleInHallway.Wait()
  1. 我对尝试次数进行了人为限制,以便该程序结束。 在一个有活锁的程序中,可能没有这种限制,这就是为什么它是一个现实工作中的问题。
  2. 首先,这个人会试图向左走,如果失败了,会尝试向右走。
  3. 这个变量为程序提供了等待,直到两个人都能够相互通过或放弃。

程序会产生如下输出:

Alice is trying to scoot: left right left right left right left right left right Alice tosses her hands up in exasperation!
Barbara is trying to scoot: left right left right left right left right left right
Barbara tosses her hands up in exasperation!

你可以看到Alice和Barbara在最终放弃之前持续交互。

这个例子演示了一个非常常见的活锁写入原因:两个或多个并发进程试图在没有协调的情况下防止死锁。 如果走廊里的人们一致认为只有一个人会移动,那么就不会有活锁:一个人静止不动,另一个人移动到另一边,他们会继续走路。

在我看来,活锁比死锁更难以发现,因为它看起来好像程序正在工作。 如果活锁程序在你的机器上运行,并且你查看了CPU利用率以确定它是否在执行任何操作,那么你可能会认为它是。 根据活锁的不同,它甚至可能会发出其他信号,使你认为它正在工作。 然而,一直以来,你的程序都扮演着走廊洗牌的永恒游戏。

活锁是饥饿的问题的一个子集。 接下来我们会讨论。

最后编辑: kuteng  文档更新时间: 2021-01-02 17:30   作者:kuteng