Go 言語は struct のレシーバがポインタの場合は実体であってもポインタの場合であっても呼び出せるので、もし struct が参照カウントに従い動作する様な場合は実体でコピーされてしまっては困る場合があります。例えば以下の様なインタフェースを考えます。
package main
import (
"fmt"
"sync/atomic"
"time"
)
type foo struct {
n int64
q chan struct{}
}
func (f *foo) Add() {
if atomic.AddInt64(&f.n, 1) == 1 {
f.q = make(chan struct{})
}
}
func (f *foo) Done() {
if atomic.AddInt64(&f.n, -1) == 0 {
f.q <- struct{}{}
}
}
func (f *foo) Watch() {
<-f.q
}
func main() {
var f foo
f.Add()
f.Add()
f.Add()
go func() {
fmt.Println("いーち！")
time.Sleep(time.Second)
f.Done()
fmt.Println("にー！")
time.Sleep(time.Second)
f.Done()
fmt.Println("さーん！")
time.Sleep(time.Second)
f.Done()
}()
f.Watch()
fmt.Println("ダーッ！")
}
このコードは main の中だけで動く場合には機嫌良く動きます。次にこの処理を分散してみたい考えてみます。関数 doSomething1 と doSomething2 に foo を引数で渡します。
func doSomething1(f foo) {
time.Sleep(2 * time.Second)
fmt.Println("さーん！")
time.Sleep(time.Second)
f.Done()
}
func doSomething2(f foo) {
fmt.Println("いーち！")
time.Sleep(time.Second)
f.Done()
fmt.Println("にー！")
time.Sleep(time.Second)
f.Done()
}
func main() {
var f foo
f.Add()
f.Add()
f.Add()
go doSomething1(f)
go doSomething2(f)
f.Watch()
fmt.Println("ダーッ！")
}
この処理は一見うまく行きそうに見えます。しかし実行するとデッドロックが起きます。
いーち！
にー！
さーん！
fatal error: all goroutines are asleep - deadlock!
goroutine 1 [chan receive]:
main.(*foo).Watch(...)
C:/Users/mattn/go/src/github.com/mattn/misc/inoki_app/main.go:27
main.main()
C:/Users/mattn/go/src/github.com/mattn/misc/inoki_app/main.go:55 +0xfd
「しっかり atomic.AddInt64 を使っているのにおかしい」と思うかもしれません。しかし実際は doSomething1 や doSomething2 の引数として foo の実体を渡した際にはコピーが発生してしまいます。参照カウンタである foo.n は両方の関数に 3 が渡り、foo.n が 0 になる事はありません。もちろんこれは引数をポインタにする事で回避できます。
func doSomething1(f *foo) {
time.Sleep(2 * time.Second)
fmt.Println("さーん！")
time.Sleep(time.Second)
f.Done()
}
func doSomething2(f *foo) {
fmt.Println("いーち！")
time.Sleep(time.Second)
f.Done()
fmt.Println("にー！")
time.Sleep(time.Second)
f.Done()
}
func main() {
var f foo
f.Add()
f.Add()
f.Add()
go doSomething1(&f)
go doSomething2(&f)
f.Watch()
fmt.Println("ダーッ！")
}
こういった struct をライブラリとして提供したい場合、使い手側に「ポインタで使って欲しい」と示す事ができないと、いくらでもバグが発生してしまいます。そこで使うテクニックが noCopy です。Go 言語を知っていてここまで読んだ方であれば、これが何かに似ていると気付いたはずです。そう sync.WaitGroup です。sync.WaitGroup も実体で引数に渡すとデッドロックが発生します。sync.WaitGroup の場合は以下のテクニックを使っています。
type WaitGroup struct {
noCopy noCopy
state1 [3]uint32
}
type noCopy struct{}
func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}
go vet は Go 言語でのお作法の良くない書き方を検出してくれるツールですが、この Lock() と Unlock() を持ったインタフェースを実体でコピーしようとすると go vet の copylocks というチェック機能により警告がでる仕組みになっています。
.\main.go:5:21: doSomething passes lock by value: sync.WaitGroup contains sync.noCopy
.\main.go:11:14: call of doSomething copies lock value: sync.WaitGroup contains sync.noCopy
実際に組み込んでみましょう。
package inoki
import (
"sync/atomic"
)
type noCopy struct{}
func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}
type Toukon struct {
noCopy noCopy
n int64
q chan struct{}
}
func (f *Toukon) Add() {
if atomic.AddInt64(&f.n, 1) == 1 {
f.q = make(chan struct{})
}
}
func (f *Toukon) Done() {
if atomic.AddInt64(&f.n, -1) == 0 {
f.q <- struct{}{}
}
}
func (f *Toukon) Watch() {
<-f.q
}
言語仕様上、禁止する事はできないのでコンパイルは出来てしまいますが、go vet を使う IDE 等ではちゃんと警告がでる様になっています。
便利なテクニックなので使ってみてみるといいと思います。
改訂2版 みんなのGo言語
松木 雅幸, mattn, 藤原 俊一郎, 中島 大一, 上田 拓也, 牧 大輔, 鈴木 健太
技術評論社 Kindle版 / ￥2,350 (2019年08月01日)
発送可能時間：
