Concurrency Bugsについての 論文を読む 2020-01-25 Umeda.go 2020 Winter LT 

About me ● twitter: @tomoz6o9 ● freee株式会社 ● Webアプリケーションエンジニア ○ RoR/React ● GoはTour of Goをやったくらい 

話すこと ● “Understanding Real-World Concurrency Bugs in Go”という論文を読ん だと言う話 ● “the morning paper”と言うサイトで紹介されているのが ● misreading chat #73 で紹介されていたのを聞いたのがきっかけ ● 詳しく知りたければ各サイトへGo 

どんな論文？ ● GoのConcurrency周りで人々がどのようなバグを犯しがちなのかの調査 ○ 対象: Docker, K8s, etcdなど ● 調査したバグをその性質、原因それぞれ2つに分類 

バグの性質 blocking bugs ● goroutineが止まってしまい動か なくなる類のバグ non-blocking bugs ● 処理自体は止まらないが、そも そも意図しない動きになってしま う類のバグ 

バグの原因 misuse of message passing ● channelが原因のバグ misuse of shared memory ● Mutex, RWMutex, WaitGroup などが原因のバグ 

結論 message passing shared memory Total blocking 49 36 85 non-blocking 17 69 86 Total 66 105 171 

Blocking × shared memory ● Goだからというよりは、いわゆる一般的なプログラミング言語と同じような 過ちが原因のバグ ○ Mutex, RWMutexでデッドロックとか ● WaitGroup起因のものはGo独特 

Non-blocking × shared memory ● これもやはり一般的なプログラミング言語と同じような過ちが多い ○ 論文内で “traditional” とされているもので50個ほど ● 残りは大別して以下の二つ ○ goroutineに渡す匿名関数内での変数スコープの誤りなど ○ WaitGroup関連 

WaitGroupに関するバグ Waitする場所間違えて 動かなくなる Addする場所間違えて すりぬける 

Blocking × message passing ● Channel周りは気をつけよう ● 例えば ○ goroutineからchannel経由でmessageを受け取り後続の処理へ ○ selectなどでtimeout処理をしたらgoroutineはchanに書き込める？ ○ →適切にBuffered Channelを使ったりする 

Non-blocking × message passing ● 少ないものの存在(例：close chan twice) ● channelの性質上正しく使えてない場合はblockingとして現れることが多 いことを考えると、正しく使いこなせればよりエラーを起こしにくい仕組みで あると言えるようだ。 

まとめ ● 他の言語でも気をつけなければいけないところはしっかり気をつけよう ● WaitGroupもケアした方がよさそう ● channelは挙動をちゃんと理解してつかおう 

thanks