プログラミング言語 Go [text.Baldanders.info]

Close 関数のエラーを無視しない（『効率的なGo』読書会より）

2025-11-15T20:04:13+09:00

『効率的なGo』の読書会は無事に最終回を迎えた。今回は，読書会最終回の範囲（11章最適化パターン）から個人的に気になった部分を取り上げる。

Close 関数のエラーを無視しない

以下のサンプルコードを起点にする。

package main

import (
	"fmt"
	"os"
)

func doWithFile(filename string) error {
	f, err := os.Open(filename)
	if err != nil {
		return err
	}
	defer f.Close()

	// Perform file operations here...

	return nil
}

func main() {
	err := doWithFile("example.txt")
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		panic(err)
	}
}

注目するのは defer f.Close() の部分。 f.Close() メソッドはエラーを返す可能性があるが，このコードではエラーを捨てている。この手のサンプルコードはよく見るし私も過去記事で書いたような気がするが，エラーハンドリングの観点からは悪いコードということになる。

ファイルアクセスではクローズ処理の際にバッファに残ってるデータをフラッシュする場合がある。特に zip ファイルの書き込み処理とかでは終端レコードをクローズ時に書き込んだりするので，絶対にエラーを無視してはいけない。

一般的にクロージング・メソッドを含むパッケージや構造体ではクローズ処理時のエラーを適切に処理する必要がある。だからといって defer を使わないのはもったいない。今回の場合は以下のように書き換える。

func doWithFile(filename string) (err error) {
	f, err := os.Open(filename)
	if err != nil {
		return err
	}
	defer func() {
		if cerr := f.Close(); cerr != nil && cerr != os.ErrClosed {
			err = errors.Join(err, cerr)
		}
	}()

	// Perform file operations here...

	return err
}

ポイントは2つ。

返り値を err error と名前付きにすること
defer 処理を無名関数 func() { ... }() で囲み，内部で適切にエラー処理を行うこと

最近の Go は（errors.Join() など）複数エラーを記述できるようになったのでハンドリングが簡潔になった¹。よしよし。

最後まで読み切ってからクローズする

次のサンプルコードはこれ。 HTTP レスポンスデータを処理する関数である。

func doWithResp(resp *http.Response) (err error) {
	defer func() {
		if cerr := resp.Body.Close(); cerr != nil && cerr != os.ErrClosed {
			err = errors.Join(err, cerr)
		}
	}()

	if resp.StatusCode != http.StatusOK {
		return fmt.Errorf("bad status: %s", resp.Status)
	}

	// Perform operations with the response

	return err
}

net/http パッケージのドキュメントには冒頭に

The caller must close the response body when finished with it:

resp, err := http.Get("http://example.com/")
if err != nil {
	// handle error
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
// ...

via http package - net/http - Go Packages

と書かれていて，必ず http.Response.Body.Close() メソッドを呼び出すよう指示されている。クローズ処理を行わないと内部でゴルーチン・リークが発生するらしい。

ただ http.Response.Body に関しては，ただクローズするだけでは駄目で，クローズする前にデータを最後まで読み切ることが推奨されている。

If the Body is not both read to EOF and closed, the Client’s underlying RoundTripper (typically Transport) may not be able to re-use a persistent TCP connection to the server for a subsequent “keep-alive” request.

via http package - net/http - Go Packages

これについては『Go言語 100Tips』にも解説がある。

もう 1 つ覚えておくべき重要なことは、ボディをクローズするときの動作は、そのボディから読み込んだかどうかによって異なることです。

読み込まずにボディをクローズすると、デフォルトの HTTP トランスポートがコネクションをクローズするかもしれません。

読み込んだ後にボディをクローズしても、デフォルトの HTTP トランスポートはコネクションをクローズしないので、再利用できる可能性があります。

したがって、getStatusCode が繰り返し呼ばれ、キープアライブ（keep-alive）のコネクションを使いたい場合、必要がないと思ってもボディを読み込むべきです。

『Go言語 100Tips』 10. No.79：一時的な資源をクローズしないより

これを踏まえて，最初のサンプルコードを書き換えると以下のようになる。

func doWithResp(resp *http.Response) (err error) {
	defer func() {
		_, rerr := io.Copy(io.Discard, resp.Body)
		if cerr := resp.Body.Close(); cerr != nil && cerr != os.ErrClosed {
			err = errors.Join(err, rerr, cerr)
		}
		err = errors.Join(err, rerr)
	}()

	if resp.StatusCode != http.StatusOK {
		return fmt.Errorf("bad status: %s", resp.Status)
	}

	// Perform operations with the response

	return err
}

余談

『効率的なGo』は，ちぃっと難しかった。何が難しいって書籍内参照が前の章や後の章に飛びまくって「何だっけこれ？」ってなることが多くて。まるで longjump だらけのスパゲッティコードを読んでる気分だった。これを曲がりなりにも理解するにはあと2,3回は周回する必要があるかな。

『効率的なGo』では標準パッケージの中身にも踏み込んでカスタマイズしたパッケージ置き換えるといったことも行っている。今回挙げた例についても，エラーハンドリングに関しては独自のパッケージが用意されている。参考になるだろう。

今回の読書会の最後の方で話題になったのだが，2025年12月に『実用 Go言語第2版』が出るそうで。買わなきゃ。先日買った『初めてのGo言語第2版』もまだ読み終わってないんだけど。

参考図書

効率的なGo ―データ指向によるGoアプリケーションの性能最適化: Bartłomiej Płotka (著), 山口能迪 (翻訳); オライリー・ジャパン 2024-02-24; 単行本（ソフトカバー）; 4814400535 (ASIN), 9784814400539 (EAN), 4814400535 (ISBN); 評価

版元で Ebook を買える。Go言語のリファレンス本ではない。フトウェア工学，プログラミング（の考え方）を学ぶ教科書的な位置づけかなぁ。

reviewed by Spiegel on 2024-04-21 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

版元で PDF 版を購入可能。事実上の Effective Go とも言える充実の内容。オリジナルは敢えてタイトルに “tips” という単語を入れるのを避けたのに邦題が「100 Tips」とかなっていて，原作者がお怒りとの噂（あくまで噂）

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

初めてのGo言語第2版 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリー・ジャパン 2025-08-05 (Release 2025-08-05); 単行本（ソフトカバー）; 4814401191 (ASIN), 9784814401192 (EAN), 4814401191 (ISBN); 評価

第2版。 Generics の説明が大幅に改訂されたらしい。練習問題も追加されている。

reviewed by Spiegel on 2025-11-02 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

拙作の goark/errs パッケージもよろしく（宣伝）。こちらも複数エラーに対応している他，エラーの出力を JSON 形式に出来る。 ↩︎

並行処理を待ち合わせる（WaitGroup と Barrier パターン）

2025-11-09T19:39:03+09:00

Go の goroutine は起動すると外側から直接制御する方法がない。とはいっても goroutine 間で同期を取ることは多く，そのための仕組みがいくつか提供されている。この記事では比較的簡単な実装である，複数の goroutine を待ち合わせる方法を紹介する。

タスクの完了を待ち合わせる

まずは5つの goroutine を起動し，それぞれ某かのタスクを実行するプログラムを考える。まずは素朴に以下のコードで¹。

package main
package main

import (
	"fmt"
	"math/rand/v2"
	"time"
)

func main() {
	tasks := 5 // Number of tasks
	for t := range tasks {
		go func() {
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	fmt.Println("All Complete")
}

（Go の関数は全て関数閉包（closure）として機能するため goroutine として定義した関数はループ変数 t を close over している。この for-range ブロックのループ変数 t は，ループするごとに新たにインスタンスが生成されている点に注意）

実際には，このコードはうまく動かない。実行するとこんな感じ：

$ go run sample1.go
All Complete

実はメイン goroutine が終了する際に他の goroutine も強制終了されてしまうため，このような結果になる。これを安直に解決する手段として，メイン goroutine を適当な時間スリープさせる方法がある。たとえばこんな感じ¹：

package main

import (
	"fmt"
	"math/rand/v2"
	"time"
)

func main() {
	tasks := 5 // Number of tasks
	for t := range tasks {
		go func() {
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	time.Sleep(10 * time.Second)
	fmt.Println("All Complete")
}

これを実行すると確かに

$ go run sample1b.go
Start Task: 5
Start Task: 4
Start Task: 2
Start Task: 1
Start Task: 3
End Task: 3
End Task: 5
End Task: 4
End Task: 1
End Task: 2
All Complete

などと一見うまく動いているようだが，このスリープ時間には根拠がないため（10秒もあれば全タスク完了してるやろ？），条件が変わればうまく動かなくなる可能性がある。

複数のタスクの完了を待ち合わせるために，標準パッケージには sync.WaitGroup が用意されている。使い方はこんな感じ：

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

func main() {
	tasks := 5             // Number of tasks
	wg := sync.WaitGroup{} // WaitGroup to synchronize goroutines
	wg.Add(tasks)          // Add the number of tasks to the WaitGroup
	for t := range tasks {
		go func() {
			defer wg.Done() // Ensure Done is called when the goroutine completes
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

これは goroutine の総数があらかじめ分かっている場合だが goroutine 数が動的に変化する場合でも使える。

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

func main() {
	wg := sync.WaitGroup{} // WaitGroup to synchronize goroutines
	for t := 1; ; t++ {
		wg.Add(1) // Add a task to the WaitGroup
		go func() {
			defer wg.Done() // Ensure Done is called when the goroutine completes
			fmt.Println("Start Task:", t)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t)
		}()
		if rand.IntN(6) > 4 { // Randomly decide to stop adding tasks
			break
		}
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

ポイントは goroutine を起動する直前に wg.Add(1) を呼び出すことである。実行結果はこんな感じ。

$ go run sample1d.go
Start Task: 3
Start Task: 1
Start Task: 2
End Task: 2
End Task: 1
End Task: 3
All Complete

for ブロックのループ変数について

先ほどのサンプルコードでは for ブロック

for t := 1; ; t++ {
    ...
}

で宣言したループ変数 t をそのまま goroutine 内で参照しているが，古いバージョンの Go では意図しない出力になる。これはループ変数 t が for ブロック内で単一のインスタンスになっていて，ループするごとに値が上書きされるためである。この問題を回避するために以下のように t を shadowing する方法が推奨されていた。

for t := 1; ; t++ {
    t := t // Shadowing to capture the current value of t
    ...
}

最近のバージョン（1.22 以降）では for ブロック内でループ変数が内部の関数（閉包）から直接参照されている場合は暗黙的に shadowing が行われる。上述のような記述は不要になったわけだ。

WaitGroup.Go メソッド

Go 1.25 で sync.WaitGroup に Go() メソッドが追加された。実装はこんな感じ。

// Go calls f in a new goroutine and adds that task to the [WaitGroup].
// When f returns, the task is removed from the WaitGroup.
//
// The function f must not panic.
//
// If the WaitGroup is empty, Go must happen before a [WaitGroup.Wait].
// Typically, this simply means Go is called to start tasks before Wait is called.
// If the WaitGroup is not empty, Go may happen at any time.
// This means a goroutine started by Go may itself call Go.
// If a WaitGroup is reused to wait for several independent sets of tasks,
// new Go calls must happen after all previous Wait calls have returned.
//
// In the terminology of [the Go memory model], the return from f
// "synchronizes before" the return of any Wait call that it unblocks.
//
// [the Go memory model]: https://go.dev/ref/mem
func (wg *WaitGroup) Go(f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		f()
	}()
}

つまり，Go() メソッド内部で Add(1) と Done() が呼び出され，かつ引数の関数 f を goroutine として起動する。これを使うと，以下のようにコードが簡潔になる。

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

func main() {
	tasks := 5             // Number of tasks
	wg := sync.WaitGroup{} // WaitGroup to synchronize goroutines
	for t := range tasks {
		wg.Go(func() {
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		})
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

この辺も定番の慣用句（idiom）だったので，Go() メソッドの追加は嬉しい改善点と言えるだろう。

タスクの開始を待ち合わせる

前節とは異なり，特定の条件が成立するまで各 goroutine を停止し，条件が成立したら一斉に実行を再開したい場合がある。条件が成立するまでタスクを止めるため，この実装パターンをバリア（Barrier）と呼ぶ。

Go の標準パッケージにはバリア・パターンを直接提供する仕組みはないが，条件変数を制御する sync.Cond を用いて比較的簡単に実装できる。

前節のコードを元に，指定した数の goroutine の起動が揃うまで待機し，揃った時点で一斉にタスクを開始するコードを実装してみよう。まずはバリアパターンを駆動する構造体 Barrier を定義する。

type Barrier struct {
	total int // Number of goroutines to wait for
	count int // Current count of arrived goroutines
	cond  *sync.Cond // Condition variable to manage waiting and signaling
}

この構造体の初期化関数を以下のように定義する。

func NewBarrier(total int) *Barrier {
	return &Barrier{
		total: total,
		count: 0,
		cond:  sync.NewCond(&sync.Mutex{}),
	}
}

さらに Barrier に対して Wait() メソッドを定義する。

func (b *Barrier) Wait() {
	b.cond.L.Lock()         // Acquire the lock before modifying count
	defer b.cond.L.Unlock() // Ensure the lock is released when done
	b.count++               // Increment the count of arrived goroutines
	if b.count >= b.total {
		b.count = 0
		b.cond.Broadcast() // Wake up all waiting goroutines
	} else {
		b.cond.Wait() // Wait until the barrier is released
	}
}

Wait() メソッドが呼ばれるたびに count がインクリメントされ，count が total に達したら cond.Broadcast() メソッドで全ての待機中 goroutine を起こす。

Barrier を使った main() 関数はこんな感じ：

func main() {
	tasks := 5                   // Number of tasks
	barrier := NewBarrier(tasks) // Create a barrier for the tasks
	for t := range tasks {
		go func() {
			time.Sleep(time.Duration(rand.IntN(3)+1) * time.Second) // Simulate preparation time
			fmt.Println("Ready Task:", t+1)
			barrier.Wait() // Wait at the barrier
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	time.Sleep(10 * time.Second)
	fmt.Println("All Complete")
}

これを実行するとこんな感じになる。

$ go run sample2.go
Ready Task: 2
Ready Task: 3
Ready Task: 1
Ready Task: 4
Ready Task: 5
Start Task: 5
Start Task: 4
Start Task: 3
Start Task: 2
Start Task: 1
End Task: 2
End Task: 1
End Task: 3
End Task: 4
End Task: 5
All Complete

各 goroutine とも Ready 状態が揃ってからタスクを開始しているのが分かる²。

さらにこれに前節の完了待ち合わせ機能を入れたコード全体は以下の通り：

package main

import (
	"fmt"
	"math/rand/v2"
	"sync"
	"time"
)

type Barrier struct {
	total int        // Number of goroutines to wait for
	count int        // Current count of arrived goroutines
	cond  *sync.Cond // Condition variable to manage waiting and signaling
}

func NewBarrier(total int) *Barrier {
	return &Barrier{
		total: total,
		count: 0,
		cond:  sync.NewCond(&sync.Mutex{}),
	}
}

func (b *Barrier) Wait() {
	b.cond.L.Lock()         // Acquire the lock before modifying count
	defer b.cond.L.Unlock() // Ensure the lock is released when done
	b.count++               // Increment the count of arrived goroutines
	if b.count >= b.total {
		b.count = 0
		b.cond.Broadcast() // Wake up all waiting goroutines
	} else {
		b.cond.Wait() // Wait until the barrier is released
	}
}

func main() {
	tasks := 5                   // Number of tasks
	barrier := NewBarrier(tasks) // Create a barrier for the tasks
	wg := sync.WaitGroup{}       // WaitGroup to synchronize goroutines
	wg.Add(tasks)                // Add the number of tasks to the WaitGroup
	for t := range tasks {
		go func() {
			defer wg.Done()                                         // Ensure Done is called when the goroutine completes
			time.Sleep(time.Duration(rand.IntN(3)+1) * time.Second) // Simulate preparation time
			fmt.Println("Ready Task:", t+1)
			barrier.Wait() // Wait at the barrier
			fmt.Println("Start Task:", t+1)
			time.Sleep(time.Duration(rand.IntN(5)+1) * time.Second) // Random duration between 1 and 5 seconds
			fmt.Println("End Task:", t+1)
		}()
	}
	wg.Wait() // Wait for all goroutines to finish
	fmt.Println("All Complete")
}

起動条件は何でもいい。今回のように決められた数の goroutine が揃ったら即起動でもいいし，特定の時刻が来たら待機中の goroutine を起こすでもいいだろう。 Channel と組み合わせる方法もあるかも知れない。

ブックマーク

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

読書会のために購入。インプレス社の本は Kindle 版より版元で PDF 版を買うのがオススメ。「並行処理」について原理的な解説から丁寧に書かれている。 Go で解説されているが Go 以外の言語でも応用できる。

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

初めてのGo言語第2版 ―他言語プログラマーのためのイディオマティックGo実践ガイド: Jon Bodner (著), 武舎広幸 (翻訳); オライリー・ジャパン 2025-08-05 (Release 2025-08-05); 単行本（ソフトカバー）; 4814401191 (ASIN), 9784814401192 (EAN), 4814401191 (ISBN); 評価

第2版。 Generics の説明が大幅に改訂されたらしい。練習問題も追加されている。

reviewed by Spiegel on 2025-11-02 (powered by PA-APIv5)

for i := range n { ... } は Go 1.22 で導入された range over int と呼ばれる構文で，for i := 0; i < n; i++ { ... } と同じ意味になる。糖衣構文（syntactic sugar）の一種ですな。 ↩︎ ↩︎
今回の記事は『Go言語で学ぶ並行プログラミング』を参考にしている。 sync.Cond の Broadcast() メソッドは待機中の全ての goroutine を起こすため，実際には起こされたタイミングで本当に条件を満たしているかどうか確認する処理が必要かもしれない。もし条件を満たしていなければ再び Wait() する。 ↩︎

struct2flag でコマンドライン解析【追記あり】

2025-10-13T03:28:30+09:00

flag 標準パッケージによるコマンドライン解析

いきなりだが，以下のコードから始める。

package main

import (
    "flag"
    "fmt"
    "strings"
)

var n = flag.Bool("n", false, "omit trailing newline")
var sep = flag.String("s", " ", "separator")

func main() {
    flag.Parse()
    fmt.Print(strings.Join(flag.Args(), *sep))
    if !*n {
        fmt.Println()
    }
}

『プログラミング言語Go』p.36-37より

これはコマンドラインの文字列をそのまま出力するプログラムで，こんなふうに動作する。

$ go run echo4.go May the Force be with you
May the Force be with you

-s オプションで区切り文字を指定できる。こんな感じ。

$ go run echo4.go -s / May the Force be with you
May/the/Force/be/with/you

また -n オプションを指定すると，末尾の改行が抑制される。さらに -h オプションでヘルプが表示される。

$ go run echo4.go -h
Usage of /home/username/.cache/go-build/06/06a6e71bb093bd1ebbb176c5042329730592597ae86dcb2ca99b3759e1aecb18-d/echo4:
  -n    omit trailing newline
  -s string
        separator (default " ")

これらオプションの解析を行っているのが標準パッケージ flag である。上述のコード例は簡単なのでアレでいいのだが，オプションに紐付けられた変数をひとつずつ定義して取り回しするのは面倒なので，普通は構造体にまとめる。例えばこんな感じ（エラーハンドリングをサボっているがご容赦）。

package main

import (
    "flag"
    "fmt"
    "strings"
)

type Flags struct {
    N   bool
    Sep string
}

func (f *Flags) Bind() {
    flag.BoolVar(&f.N, "n", false, "omit trailing newline")
    flag.StringVar(&f.Sep, "s", " ", "separator")
}

func main() {
    f := &Flags{}
    f.Bind()
    flag.Parse()
    fmt.Print(strings.Join(flag.Args(), f.Sep))
    if !f.N {
        fmt.Println()
    }
}

オプションを構造体にまとめるメリットはもうひとつあって，それは facade パターンを構成してコマンドライン制御とロジックを簡単に分離できることである。例えばこんな感じ。

package main

import (
    "flag"
    "fmt"
    "strings"
)

type Flags struct {
    N    bool
    Sep  string
    Strs []string
}

func (f *Flags) Bind() {
    flag.BoolVar(&f.N, "n", false, "omit trailing newline")
    flag.StringVar(&f.Sep, "s", " ", "separator")
}

func Echo(f *Flags) {
    fmt.Print(strings.Join(f.Strs, f.Sep))
    if !f.N {
        fmt.Println()
    }
}

func main() {
    f := &Flags{}
    f.Bind()
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

これで main() 関数はコマンドライン制御に徹してロジックを Echo() 関数に任せることができる。一方で Echo() 関数は渡される Flags 構造体にのみ依存しているのでコマンドライン制御の詳細を知らなくて済む。この例では全てが main パッケージにまとまってるので分かりにくいが，ロジックを別パッケージにすることはよくあるので，テストのしやすさも考慮してこのパターンを意識するのは大事である。

とはいえ，ロジックが変われば要求される情報も変わるし，上の例でいう Flags 構造体の中身も変わる。そうなると Flags.Bind() メソッドの中身も変える必要があるが，このメソッドで構造体の要素をひとつづつ flag パッケージに紐付けているので，これを書くのが地味に面倒くさいのである。そもそも flag パッケージに紐付ける処理が構造体側にあるのもイマイチだよね。

struct2flag でコマンドライン解析

というところで github.com/hymkor/struct2flag パッケージの登場である。これを使ってコードを書き直してみる。

package main

import (
    "flag"
    "fmt"
    "strings"

    "github.com/hymkor/struct2flag"
)

type Flags struct {
    N    bool   `flag:"n,omit trailing newline"`
    Sep  string `flag:"s,separator"`
    Strs []string
}

func NewFlags() *Flags {
    return &Flags{N: false, Sep: " ", Strs: []string{}}
}

func Echo(f *Flags) {
    fmt.Print(strings.Join(f.Strs, f.Sep))
    if !f.N {
        fmt.Println()
    }
}

func main() {
    f := NewFlags()
    struct2flag.BindDefault(f)
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

struct2flag を使うことにより flag との紐づけ情報は Flags 構造体定義のタグとインスタンス生成・初期化を行う NewFlags() 関数に集約される（インスタンスの値が各オプションの既定値として登録されるため）。

struct2flag を使うメリットはいくつかあって

main() 関数側はオプション値を格納する構造体の詳細を知らなくてもよい
構造体のタグが各要素の簡単な説明になっている
struct2flag の中身がシンプルで標準以外の依存パッケージがない

といったところであろう。

私は，ちゃんとしたコマンドラインツールを作るときはサブコマンドや GNU 拡張シンタックスが使える cobra を使ったりしているのだが，ちょっとしたツールには大げさなんだよね，これ。かといって flag を素のまま使うのは微妙に鬱陶しくて，結局コマンドラインオプション無しで main() 関数に直接値を埋め込んでしまうことが多い。

struct2flag なら構造体にタグを書くだけで済むし flag を素のまま使うよりは気軽にコマンドラインオプションを構成できるので，ちょっとしたツールにはいい感じである。

公開してくださった @zetamatta@mstdn.jp さんに感謝 🙇

【2025-10-18 追記】オプションの既定値を設定ファイルから取得する

前節では Flags 構造体の初期値を固定値にしていたが，これを設定ファイルから取得できるようにしてみる。設定ファイルの内容は以下の JSON 形式とする。

{
  "no_newline": true,
  "separator": "/"
}

さらに Flags 構造体のタグを以下のように書き換える。

type Flags struct {
    N    bool   `flag:"n,omit trailing newline" json:"no_newline"`
    Sep  string `flag:"s,separator" json:"separator"`
    Strs []string
}

読み込む処理は以下の通り（main() 関数のみ表示）。

const configPath = "echo/config.json"

func main() {
    f := NewFlags()
    if conf, err := os.UserConfigDir(); err == nil {
        if data, err := os.ReadFile(filepath.Join(conf, configPath)); err == nil {
            if err := json.Unmarshal(data, f); err != nil {
                fmt.Fprintln(os.Stderr, err)
                return
            }
        }
    }
    struct2flag.BindDefault(f)
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

これで設定ファイルが存在する場合はその内容を規定値とし，存在しない場合（または読み込みに失敗した場合）はスルーする。 os.UserConfigDir() って何？って方は（ちょっと古いけど）拙文「go-homedir はもう要らない」あたりを参考にどうぞ。

実行結果はこんな感じ。

$ go run echo4e.go May the Force be with you
May/the/Force/be/with/you

オプション値を設定ファイルで取得できるようにすると何が嬉しいかというと，バッチ処理を構成しやすくなるのよ。設定ファイル自体が「どういう条件でコマンドを実行したか」という証跡になるし，コマンドラインを短くできるのも嬉しい。

【2025-10-18 追記】オプションの既定値を環境変数から取得する

struct2flag の作者の方が構造体のタグと環境変数を紐付けて取得するパッケージ github.com/hymkor/struct2env も公開された。構造体のタグはこんな感じに定義する。

type Flags struct {
    N    bool   `flag:"n,omit trailing newline" env:"NO_NEWLINE"`
    Sep  string `flag:"s,separator" env:"SEPARATOR"`
    Strs []string
}

読み込む処理は以下の通り（main() 関数のみ表示）。

func main() {
    f := NewFlags()
    struct2env.Bind(f)
    struct2flag.BindDefault(f)
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

実行結果はこんな感じ。

$ env SEPARATOR=/ go run echo4f.go May the Force be with you
May/the/Force/be/with/you

まぁ，今回みたいにコマンドラインオプションと環境変数で同じ情報を取得するのはメリットが薄いかもしれないけど（Docker 環境では重宝するかも），ある値は環境変数から取得し別の値はコマンドラインから取得する，みたいな使い方はアリかなと思ったりする。ともかく，環境変数の情報を（構造体のタグ付けで）一度に取得できるのはかなり便利である。

【2025-10-19 追記】別解

struct2env ほど便利ではないが，一応別解もある。

func main() {
    f := NewFlags()
    struct2flag.BindDefault(f)
    flag.VisitAll(func(f *flag.Flag) {
        if s := os.Getenv(strings.ToUpper(f.Name)); s != "" {
            _ = f.Value.Set(s)
        }
    })
    flag.Parse()
    f.Strs = flag.Args()

    Echo(f)
}

これはオプション名と同名の環境変数を探して既定値としてセットするもので，実行するとこんな感じになる。

$ env S=/ go run echo4g.go May the Force be with you
May/the/Force/be/with/you

標準パッケージのみで構成できるのがメリットだが，このままだと1文字のオプション名もそのまま環境変数名として検索されることになるので，実際に使うには変換ルールを工夫する必要があるかもしれない。それを考えると struct2env のほうが自由度が高くていいかも。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

“Philosophers” を Go で解く（CLI）

2025-09-03T18:34:53+09:00

コマンドライン・インタフェース

実際に問題を解く前にコマンドライン・インタフェースを整えておく。 CLI には spf13/cobra パッケージを使用する。詳細については，ちょっと古い内容だが「Cobra でテストしやすい CLI を構成する」を参考にどうぞ。この記事では結果だけ示す。

$ go run github.com/spiegel-im-spiegel/philo -h
Simulation for philosophers' problem.

Usage:
  philo [flags]
  philo [command]

Available Commands:
  help        Help about any command
  version     print the version number

Flags:
      --debug   for debug
  -h, --help    help for philo

Use "philo [command] --help" for more information about a command.

なおリポジトリは以下にある。

Philosophers - I never thought philosophy would be so deadly

パラメータの定義

問題で指示されているパラメータを今一度挙げる。

シンボル型説明

NumPhilos int 哲学者およびフォークの数（$\ge 2$）

TimeDie int 餓死するまでの時間（$\gt 0\,\mathrm{ms}$）

TimeEat int 「食べる」時間（$\gt 0\,\mathrm{ms}$）

TimeSleep int 「眠る」時間（$\gt 0\,\mathrm{ms}$）

TimeThink int 「考える」時間（$\ge 0\,\mathrm{ms}$）

NumEat int 各哲学者が最低限食事を行う回数（$\ge 0$）

これをコマンドラインから設定できるようにする。先に指定したパラメータを格納する型を定義しよう。

// Params holds tunable configuration values for a Dining Philosophers simulation.
type Params struct {
	NumPhilos int // Total number of philosophers (and forks). Must be >= 2.
	TimeDie   int // Maximum time in milliseconds a philosopher can go without eating before being considered dead.
	TimeEat   int // Time in milliseconds a philosopher spends eating (holding both forks).
	TimeSleep int // Time in milliseconds a philosopher sleeps after eating.
	TimeThink int // Optional target time in milliseconds a philosopher thinks after sleeping.
	NumEat    int // Optional target number of meals each philosopher must consume; if == 0 the simulation runs until a death occurs.
}

// String returns a human-readable summary of the Params configuration,
// listing the number of philosophers, each lifecycle duration (die, eat,
// sleep, think in milliseconds), and the required number of meals.
// Example:
//
//	Philosophers: 5, Die: 800ms, Eat: 200ms, Sleep: 200ms, Think: 0ms, Eat Count: 3
func (p *Params) String() string {
	return fmt.Sprintf("Philosophers: %d, Die: %dms, Eat: %dms, Sleep: %dms, Think: %dms, Eat Count: %d",
		p.NumPhilos, p.TimeDie, p.TimeEat, p.TimeSleep, p.TimeThink, p.NumEat)
}

いやぁ，今どきは AI がコメントを書いてくれるから楽でいいね（笑）これを前節の CLI と接続する。こんな感じ。

$ go run github.com/spiegel-im-spiegel/philo -h
Simulation for philosophers' problem.

Usage:
  philo [flags]
  philo [command]

Available Commands:
  help        Help about any command
  version     print the version number

Flags:
      --debug              for debug
  -h, --help               help for philo
  -m, --must-eat int       number of times each philosopher must eat (default 3)
  -p, --philosophers int   number of philosophers (default 5)
  -d, --to-die int         time to die (ms) (default 200)
  -e, --to-eat int         time to eat (ms) (default 20)
  -s, --to-sleep int       time to sleep (ms) (default 80)
  -t, --to-think int       time to think (ms) (default 80)

Use "philo [command] --help" for more information about a command.

デフォルト値は適当で。今のところはパラメータの内容を表示するだけの処理にしておく。

$ go run github.com/spiegel-im-spiegel/philo -h
Philosophers: 5, Die: 200ms, Eat: 20ms, Sleep: 80ms, Think: 80ms, Eat Count: 3

CLI 部分はここまで。これで本来のシミュレーション・ロジックを組み込む準備は完了である。次回から実際に問題を解いていく。

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Goならわかるシステムプログラミング第2版: 渋川よしき (著), ごっちん (イラスト); ラムダノート 2022-03-23; 単行本（ソフトカバー）; 4908686122 (ASIN), 9784908686122 (EAN), 4908686122 (ISBN); 評価

第1版はとてもためになる内容だったので第2版も PDF 版で確保しておく。

reviewed by Spiegel on 2022-10-08 (powered by PA-APIv5)

“Philosophers” を Go で解く（問題編）

2025-09-02T15:05:52+09:00

先日書いた読書感想文の最後の方で「食事する哲学者の問題」を紹介したが，今回から数回に渡ってこの問題を Go で解く記事を書いてみる。

読書会で教えて頂いたテキストは “Philosophers - I never thought philosophy would be so deadly” というのだが，ググっても（フリーで使えそうな）オリジナルっぽい文書が見つからないので，問題について説明するところから始めたいと思う（今回のために多少アレンジしている。あしからず）。

基本ルール

まず，基本のルールについて。

円卓に2人以上の哲学者が座っている
哲学者は「食べる」→「眠る」→「考える」のローテーションを逐次繰り返す。哲学者間で行動の差異はない
- 「食べる」間は「眠る」「考える」を行わない
- 「眠る」間は「食べる」「考える」を行わない
- 「考える」間は「食べる」「眠る」を行わない
円卓の中央には大きなスパゲッティボールがあり，哲学者は食事の際はそれぞれボールからスパゲッティを取って「食べる」
スパゲッティを取って食べるためのフォークは哲学者の人数分だけあり，各哲学者から見て左右に1本ずつ配置されている
「食べる」際はフォークが必ず2本必要。各哲学者は左右にある2本のフォークを取って「食べる」を開始する（他のフォークは使わない）
- フォークを使っている間は他の哲学者は同じフォークを使えない
- 「食べる」が終わったらフォークを戻し，他の哲学者が使えるようにする
「食べる」が終わったら「眠る」を開始する。「眠る」は一定時間行う
「眠る」が終わったら「考える」を開始する。「考える」は次の「食べる」を開始するまで継続する
哲学者はお互いの状態を知らず，コミュニケーションすることもない
哲学者は一定時間「食べる」をしないと餓死する

スパゲッティ・フォーク・哲学者の配置を簡単に図示してみる（図は哲学者が5人の場合）。

via “SE 350 Textbook Notes - Sentences” (CC-BY-NC)

同じフォークを哲学者同士で使い回すんかい！とか，スパゲッティの補充はどうするの？とか生々しい話はいったん考えない。まぁ，哲学者って ~~頭おかしい~~ 変わり者が多そうだし（笑）

このルール下で餓死者を出さずに全員が一定回数以上食事を行うにはどうすればいいか，という問いである。このシミュレーションを Go で組んでみよう，というわけだ。

パラメータおよび終了条件

シミュレーションに必要な各種パラメータを以下に示す。

シンボル	型	説明
`NumPhilos`	`int`	哲学者およびフォークの数（$\ge 2$）
`TimeDie`	`int`	餓死するまでの時間（$\gt 0\,\mathrm{ms}$）
`TimeEat`	`int`	「食べる」時間（$\gt 0\,\mathrm{ms}$）
`TimeSleep`	`int`	「眠る」時間（$\gt 0\,\mathrm{ms}$）
`TimeThink`	`int`	「考える」時間（$\ge 0\,\mathrm{ms}$）
`NumEat`	`int`	各哲学者が最低限食事を行う回数（$\ge 0$）

シミュレーションの終了条件は以下の通り：

哲学者はシミュレーション開始または食事を開始してから TimeDie ミリ秒以内に次の食事を始めないと餓死する
哲学者の誰か1人が餓死した場合または全員が NumEat 回以上食事を行った場合はシミュレーションを終了する
- デッドロックを検出した場合は餓死確定とみなしてシミュレーションを終了する（Go ランタイムの標準機能¹）
- NumEat が 0 の場合は誰かが餓死しない限り処理を継続する

その他注意事項およびヒント

パラメータを含め，変数をグローバル変数として配置しない
以下のイベントに対してログを出力する。タイムスタンプはミリ秒単位
- 哲学者 X がフォークを持った
- 哲学者 X がフォークを戻した
- 哲学者 X が「食べる」を開始した
- 哲学者 X が「寝る」を開始した
- 哲学者 X が「考える」を開始した
- 哲学者 X が餓死した
シミュレーション部分に関しては Go の標準パッケージのみ使用する
哲学者の行動は goroutine による並行処理として実装する
フォークは哲学者間の共有資源とみなし mutex を使って排他制御を行う²
スパゲッティは無尽蔵かつ専有不可であるとみなし，排他制御の対象としない

こんなところかな。さぁ，みんなで考えよう！（続く）

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Goならわかるシステムプログラミング第2版: 渋川よしき (著), ごっちん (イラスト); ラムダノート 2022-03-23; 単行本（ソフトカバー）; 4908686122 (ASIN), 9784908686122 (EAN), 4908686122 (ISBN); 評価

第1版はとてもためになる内容だったので第2版も PDF 版で確保しておく。

reviewed by Spiegel on 2022-10-08 (powered by PA-APIv5)

Go ランタイムは全ての goroutine が停止するとデッドロックとみなしてプロセスを終了する。なお Sleep 等のタイマーやネットワーク通信などの一時停止状態は除く。 ↩︎
Go の標準パッケージでは semaphore は（ユーザが利用できる形では）提供されていない。事実上の準標準パッケージとしては golang.org/x/sync/semaphore が重み付きセマフォ（weighted semaphore）として公開されている。 ↩︎

『Go言語で学ぶ並行プログラミング』の練習問題より

2025-04-17T19:47:01+09:00

今回は読書会じゃなくて Bluesky からのネタ¹。

Go言語で学ぶ並行プログラミングの4章の hello world みたいな練習問題、すでにめっちゃ難しいんだけど、この答えの 26行目は lock とらないでいいの？ (4.3 練習問題 1) github.com/cutajarj/Con...

[image or embed]
— ikawaha (@ikawaha.bsky.social) April 16, 2025 at 11:57 PM

「4.3 練習問題」の1というのがこれ。

リスト 4.15（もともとは第 3 章から）は、共有変数へのアクセスを保護するためのミューテックスを使っていません。これは悪い習慣です。このプログラムを変更して、共有変数 seconds へのアクセスをミューテックスで保護するようにしてください。ヒント：変数をコピーする必要があるかもしれません。

『Go言語で学ぶ並行プログラミング』4.3節よりより

んで「リスト 4.15」というのがこちら：

package main

import (
    "fmt"
    "time"
)
func countdown(seconds *int) {
    for *seconds > 0 {
        time.Sleep(1 * time.Second)
        *seconds -= 1
    }
}

func main() {
    count := 5
    go countdown(&count)
    for count > 0 {
        time.Sleep(500 * time.Millisecond)
        fmt.Println(count)
    }
}

簡単なカウントダウンのプログラムだけど，カウントダウンを goroutine で実行しているのがポイント。 main() の count 変数が2つの goroutine で使われているの（countdown() 関数側は seconds）がお分かりだろうか。

で，この問題の回答は GitHub リポジトリで公開されている。こんな感じ：

package main

import (
    "fmt"
    "sync"
    "time"
)

func countdown(seconds *int, mutex *sync.Mutex) {
    mutex.Lock()
    remaining := *seconds
    mutex.Unlock()
    for remaining > 0 {
        time.Sleep(1 * time.Second)
        mutex.Lock()
        *seconds -= 1
        remaining = *seconds
        mutex.Unlock()
    }
}

func main() {
    mutex := sync.Mutex{}
    count := 5
    go countdown(&count, &mutex)
    remaining := count
    for remaining > 0 {
        time.Sleep(500 * time.Millisecond)
        mutex.Lock()
        fmt.Println(count)
        remaining = count
        mutex.Unlock()
    }
}

上で強調している行はロック取ってないよね，というのが最初のポストの内容というわけだ。

ちょっとややこしいのだが，もともとこの練習問題の回答としては

func main() {
    mutex := sync.Mutex{}
    count := 5
    go countdown(&count, &mutex)
    for count  > 0 {
        time.Sleep(500 * time.Millisecond)
        mutex.Lock()
        fmt.Println(count)
        mutex.Unlock()
    }
}

が提示されていたらしい（countdown() 関数は省略して main() 関数のみ挙げている）。これだと for ループの条件文で count を直接参照しているので拙いよね，という指摘があったのだが，この指摘に対応しようとして失敗しているように見える。

おそらく main() 関数を修正するのであれば以下が妥当だと思う。

func main() {
    mutex := sync.Mutex{}
    count := 5
    remaining := count
    go countdown(&count, &mutex)
    for remaining > 0 {
        fmt.Println(remaining)
        time.Sleep(500 * time.Millisecond)
        mutex.Lock()
        remaining = count
        mutex.Unlock()
    }
}

まず remaining 変数の初期化宣言を goroutine 起動前に行う。さらに for ループ内の fmt.Println() を remaining 変数を参照するよう変更する（こうすることで fmt.Println() をロックの外に出せる。なお，上のコードではカウント 0 を出力しないよう fmt.Println() 関数の位置を変えている）。

といったところだろうか。

問題は最初の回答コードでも，その後の不完全修正コードでも，たぶん支障なく動いてしまうところなんだよね。だってカウントダウンさせてる int 型の共有変数を参照してるだけだもん。参照時に多少の不整合が起きても，おそらく見た目では分からない。

著者の方も指摘に対して

Thank you for spotting this. This is proof that race conditions are easy to miss!

via GitHub Issue #2

と返しておられる通り，並行処理のデバッグがいかに難しいか分かる。ただ，共有変数 count へアクセスする際に「不変式が真²」であることをきちんと保証するためには，この実装をサボってはいけない。

Go に詳しい方なら「for 文で回さなくても channel を使えばいいし，なんなら atomic パッケージも使えるぢゃん」と思うだろう（そしてそれは正しい）が『Go言語で学ぶ並行プログラミング』では4章でようやく sync.Mutex が登場したところで， channel は7章， atomic パッケージは12章で登場する。あしからず。なお『Go言語で学ぶ並行プログラミング』本編には言及が見当たらないが sync.Mutex は再入不可である³。

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

𝕏 の TL はホンマにウザいので，エンジニアの方々は Bluesky に来て欲しい，マジで。 ↩︎
不変式の話は『プログラミング言語Go』に出てくる。また『Go言語で学ぶ並行プログラミング』の「訳者あとがき」でも『プログラミング言語Go』の内容を紹介する形で説明がある。でも『プログラミング言語Go』は絶版状態なんだよなぁ orz ↩︎
再入云々については『Go言語で学ぶ並行プログラミング』の「訳者あとがき」に解説がある。たとえば Java のミューテックスは再入可能なため，その辺の差異について認識しておく必要がある。 ↩︎

条件変数とセマフォ（『Go言語で学ぶ並行プログラミング』読書会3回目）

2025-03-22T23:49:15+09:00

「第3回『Go言語で学ぶ並行プログラミング』オンライン読書会」の話題より。ちなみに第2回は記事にしていない。あしからず。

条件変数

条件変数（condition variable）は，ミューテックス（mutex）と組み合わせて，並行処理を特定の条件が発生するまで待たせたいときに使う。

Go では標準パッケージの sync.Cond 型で提供されている。こんな感じで使う。

cond := sync.NewCond(&sync.Mutex{})

ちなみに Java では

final Lock lock = new ReentrantLock();
final Condition condLock  = lock.newCondition();

みたいな感じにミューテックス・インスタンスから生成する。おそらく言語やライブラリやフレームワークによって色々あるだろう。

それはさておき『Go言語で学ぶ並行プログラミング』に出ていた例題は

Stingy と Spendy の２人の登場人物（goroutine）
２人は共通の銀行口座を持っていて現在100ドルの残高がある
Stingy は毎回10ドルずつ100万回入金する
Spendy は毎回50ドルずつ20万回出金する
銀行口座の残高をマイナスにしてはいけない（← ここが条件変数の条件）

という要件で入出金の様子をコードで書くというもの。過程をすっ飛ばして最終形を挙げておく。

package main

import (
    "fmt"
    "os"
    "sync"
    "time"
)

func main() {
    money := 100
    mutex := sync.Mutex{}
    cond := sync.NewCond(&mutex)
    go stingy(&money, cond)
    go spendy(&money, cond)
    time.Sleep(2 * time.Second)
    mutex.Lock()
    fmt.Println("Money in bank account: ", money)
    mutex.Unlock()
}

func stingy(money *int, cond *sync.Cond) {
    for i := 0; i < 1000000; i++ {
        cond.L.Lock()
        *money += 10
        cond.Signal()
        cond.L.Unlock()
    }
    fmt.Println("Stingy Done")
}

func spendy(money *int, cond *sync.Cond) {
    for i := 0; i < 200000; i++ {
        cond.L.Lock()
        for *money < 50 {
            cond.Wait()
        }
        *money -= 50
        if *money < 0 {
            fmt.Println("Money is negative!")
            os.Exit(1)
        }
        cond.L.Unlock()
    }
    fmt.Println("Spendy Done")
}

『Go言語で学ぶ並行プログラミング』第5章より

spendy() 関数内 cond.Wait() の動作は分かりにくいかもしれないが，内部ではミューテックスを解放して待ち状態に入っている。その後 Signal() を受け取ったらミューテックスを再取得して続きの処理を再開する。ここで *money < 50 の条件に合致すればループを抜けて出金操作を行うわけだ（合致しなければ再び Wait()）。

このコードの注意点は2つ。ひとつは Signal() や Wait() の前後は必ず Lock() ... Unlock() で囲っておくこと。もうひとつは Wait() 付近で条件を記述する際は if 文ではなく for 文でループを構成すること。後者はわかりやすいよね。前者は，たとえば以下のようなコードがあって

package main

import (
    "fmt"
    "sync"
)

/*
Note: this program has a bug for demonstration purposes
We demonstrate how to fix this problem in the next listing
*/
func doWork(cond *sync.Cond) {
    fmt.Println("Work started")
    fmt.Println("Work finished")
    cond.Signal()
}

func main() {
    cond := sync.NewCond(&sync.Mutex{})
    cond.L.Lock()
    for i := 0; i < 50000; i++ {
        go doWork(cond)
        fmt.Println("Waiting for child goroutine")
        cond.Wait()
        fmt.Println("Child goroutine finished")
    }
    cond.L.Unlock()
}

『Go言語で学ぶ並行プログラミング』第5章より

これを実行すると大抵は（Wait() で受ける相手が起動する前に Signal() を投げちゃうので）デッドロック状態になるのだが¹，状態によっては上手く動いてしまうことがあるのよ。動いたり動かなかったりするってのが一番厄介。

ちなみに Java の条件変数の場合は，ロックをせずにシグナルを投げようとすると例外が発生するらしい。

そういえばシグナルを投げるメソッドには Broadcast() もあり，こちらは Wait() で一時停止している全ての goroutine が起こされる。 Signal() と Broadcast() のどちらを使うかは状況によると思うが，読書会主催の柴田芳樹さんは対象の goroutine のうちどれが起きるのか明確に分からない場合は（ひとつだけ起こしたい場合でも）なるべく Signal() ではなく Broadcast() を使うべきだと言っておられた。 Wait() で待ち状態になっている側も，どういうタイミングで起こされるか分からないので，起こされたら必ず条件判定を行って条件に合致しなければ再び Wait() するという処理が必要になる。だからループを構成するんだねぇ。

書き込み優先な RWMutex

Go では，共有資源に対して

書き込みを行うスレッド（goroutine）はひとつだけ
読み込み専用スレッドは複数ある

場合に読み込み側と書き込み側で優先度の異なるロックをかける sync.RWMutex 型ってのがある。『Go言語で学ぶ並行プログラミング』の第4章では，標準の sync.RWMutex を使わずリーダー・ライター・ミューテックスを自作している。

ただし第4章で作ったのは読み込み優先の実装だったので，読み込み側が次々とロックを取ってしまうと，いつまで経っても書き込み側がロックを取れない事態になる²。この場合はデッドロックにもならないので，これはこれで厄介である。これを解消するためには書き込み側を優先するロックにする必要がある。第5章では，条件変数を用いて，自作リーダー・ライター・ミューテックスを書き込み優先に修正するくだりがある。

『Go言語で学ぶ並行プログラミング』は比較的簡単なサンプルコードで仕組みを紹介しているのがとてもいいと思う。

ちなみに標準の sync.RWMutex は書き込み優先である。

If any goroutine calls RWMutex.Lock while the lock is already held by one or more readers, concurrent calls to RWMutex.RLock will block until the writer has acquired (and released) the lock, to ensure that the lock eventually becomes available to the writer. Note that this prohibits recursive read-locking. A RWMutex.RLock cannot be upgraded into a RWMutex.Lock, nor can a RWMutex.Lock be downgraded into a RWMutex.RLock.

だから第4章では標準の sync.RWMutex を使わなかったんだねぇ。ここで繋がったよ（笑）

セマフォ

セマフォ（semaphore）は並行処理の同時実行数を制御する仕組みである。たとえば計算資源をフルに使わせたくない場合に，ある時点の並行処理の同時実行数を（おそらくプロセッサ数以下に）抑える目的で使ったりする。

『Go言語で学ぶ並行プログラミング』では条件変数を使ってセマフォを自作している。一方 Go の標準パッケージにセマフォはないが golang.org/x/sync/semaphore パッケージを使うことでセマフォを扱うことができる。こちらはほぼ標準パッケージに近いのでバンバン使っていいだろう。

この記事では golang.org/x/sync/semaphore パッケージに載っているサンプルコードを挙げておく。

package main

import (
    "context"
    "fmt"
    "log"
    "runtime"

    "golang.org/x/sync/semaphore"
)

// Example_workerPool demonstrates how to use a semaphore to limit the number of
// goroutines working on parallel tasks.
//
// This use of a semaphore mimics a typical “worker pool” pattern, but without
// the need to explicitly shut down idle workers when the work is done.
func main() {
    ctx := context.TODO()

    var (
        maxWorkers = runtime.GOMAXPROCS(0)
        sem        = semaphore.NewWeighted(int64(maxWorkers))
        out        = make([]int, 32)
    )

    // Compute the output using up to maxWorkers goroutines at a time.
    for i := range out {
        // When maxWorkers goroutines are in flight, Acquire blocks until one of the
        // workers finishes.
        if err := sem.Acquire(ctx, 1); err != nil {
            log.Printf("Failed to acquire semaphore: %v", err)
            break
        }

        go func(i int) {
            defer sem.Release(1)
            out[i] = collatzSteps(i + 1)
        }(i)
    }

    // Acquire all of the tokens to wait for any remaining workers to finish.
    //
    // If you are already waiting for the workers by some other means (such as an
    // errgroup.Group), you can omit this final Acquire call.
    if err := sem.Acquire(ctx, int64(maxWorkers)); err != nil {
        log.Printf("Failed to acquire semaphore: %v", err)
    }

    fmt.Println(out)

}

// collatzSteps computes the number of steps to reach 1 under the Collatz
// conjecture. (See https://en.wikipedia.org/wiki/Collatz_conjecture.)
func collatzSteps(n int) (steps int) {
    if n <= 0 {
        panic("nonpositive input")
    }

    for ; n > 1; steps++ {
        if steps < 0 {
            panic("too many steps")
        }

        if n%2 == 0 {
            n /= 2
            continue
        }

        const maxInt = int(^uint(0) >> 1)
        if n > (maxInt-1)/3 {
            panic("overflow")
        }
        n = 3*n + 1
    }

    return steps
}

via semaphore package - golang.org/x/sync/semaphore - Go Packages

コラッツ予想？このサンプルでは，メイン以外の goroutine の間では共有資源の異なるアドレスにアクセスするためデータ競合（data race）は起きないことに注意。データ競合が発生し得るのであればミューテックスを使ってアクセス制御を行う必要がある。

golang.org/x/sync/semaphore パッケージで実装されているセマフォは「重み付きセマフォ（weighted semaphore）」と呼ぶらしい。 Acquire() および Release() で獲得数・解放数を指定できる。上のサンプルコードでは最後の sem.Acquire(ctx, int64(maxWorkers)) でメイン以外の goroutine が稼働していないことを確認している（稼働していれば待ちになる）。なお Release() 時にカウントがマイナスになると panic を吐くようだ。

今回はここまで

次回は第6章の「バリア（barrier）」の話からである。楽しみ！

ブックマーク

cutajarj/ConcurrentProgrammingWithGo: Listings from manning book : 『Go言語で学ぶ並行プログラミング』に出てくるサンプルコード

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go ではメインを含む全ての goroutine が待機状態になって（タイマーやシグナル等で）起こされる見込みがない状態を検出するとデッドロック（deadlock）と見なして panic を投げる。だから Go の並行処理ではデッドロックは検出しやすく，それゆえにデバッグも（比較的）しやすい。 ↩︎
リーダー・ライター・ミューテックスで書き込み側がいつまでもロックを獲得できない状態を writer-starvation と呼ぶ。『Go言語で学ぶ並行プログラミング』における “starvation” の定義は「他の貪欲な実行によって資源が長時間（または無期限に）利用できなくなり、共有資源へのアクセスを得ることができない状況を指します」としている。書き込み側が starvation になるから writer-starvation ということらしい。辞書的な “starvation” の意味は「食糧の不足によって栄養失調が続き、体調の維持が困難になっている状態」みたいな意味だそうな。継続的な飢餓状態ってことやね。 ↩︎

Go 1.24 からのベンチマークテスト

2025-03-15T21:08:09+09:00

現在『効率的なGo』の読書会に参加してるんだけど，今回はその10回目の話。

第67回横浜Go読書会（オンライン） - connpass

今回は「8章ベンチマーク」の最初の部分まで読み進めた。この辺からようやく Go のツールを使った具体的な話になってくる。

内容については本を読んでもらうとして，今回はベンチマーク・コードの話。件の本では「ほとんどのベンチマークに必要な小さなボイラープレートの生テンプレート」として以下のコードを挙げている。

func BenchmarkSum(b *testing.B) {
    b.ReportAllocs()
    // TODO(bwplotka): 必要な初期化処理を追加

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        // TODO(bwplotka): テストされた機能を追加
    }
}

『効率的なGo』リスト 8-1：Go のベンチマークの核となる要素より

ちなみに b.ReportAllocs() はヒープメモリの割り当て回数と総量をレポートするための関数で， go test -bench コマンドでベンチマークテストを起動する際の -benchmem オプションと同じ効果がある。

このコード中の for 文でカウンターを回しているのだが Go 1.24 から testing.B.Loop() メソッドが追加され for ループの記述が大きく改善された。

Benchmarks may now use the faster and less error-prone testing.B.Loop method to perform benchmark iterations like for b.Loop() { ... } in place of the typical loop structures involving b.N like for range b.N. This offers two significant advantages:

The benchmark function will execute exactly once per -count, so expensive setup and cleanup steps execute only once.

Function call parameters and results are kept alive, preventing the compiler from fully optimizing away the loop body.

via Go 1.24 Release Notes - The Go Programming Language

最初のほうの「コストのかかるセットアップおよびクリーンアップ手順は1回だけ実行される」というのは分かりにくいが，実は testing.B.Loop() メソッドを使うと，先のテンプレートコードにある b.ResetTimer() を省略できて，純粋に for b.Loop() { ... } 内の処理だけ計測される。

もうひとつはもっと重要で for b.Loop() { ... } 内のコードは最適化されないことを保証するというものだ。たとえば

func Add(a, b int) int {
	return a + b
}

という関数のベンチマークを取ろうとして素朴に

for range b.N {
    _ = Add(1, 2)
}

なんてなコードを書いたら，最悪の場合，最適化でループ内の処理がまるごと無くなりかねない¹。 testing.B.Loop() メソッドを使うことでそうした事態を回避できるというわけだ。

お試しに何か書いてみよう²。まずはこんな関数を書いてみる。

package sample

func Sum(data []int) int {
	total := 0
	for _, value := range data {
		total += value
	}
	return total
}

よくある合計値を返す関数ですな。作成した sample.Sum() 関数のベンチマークテストのコードは以下の通り。

package sample_test

import (
	"math/rand/v2"
	"sample"
	"testing"
)

func intList(n int) []int {
	list := make([]int, n)
	for i := range list {
		list[i] = rand.Int()
	}
	return list
}

func BenchmarkSum(b *testing.B) {
	b.ReportAllocs()
	input := intList(128 << 10)

	for b.Loop() {
		sample.Sum(input)
	}
}

さっそく実行してみよう³。

$ go test -run '^$' -bench '^BenchmarkSum$' -count 6 | tee sample_sum_bench_v1.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
BenchmarkSum-12        37249         32302 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        36802         32570 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        36495         34515 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        36825         32516 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        37101         32142 ns/op           0 B/op          0 allocs/op
BenchmarkSum-12        37298         32072 ns/op           0 B/op          0 allocs/op
PASS
ok      sample	7.260s

ヒープの使用もカウントされてないし，上手くいってるっぽいな。

もうひとつ。『効率的なGo』では benchstat コマンドの紹介もされていた。上のベンチマーク結果について簡単な統計処理をしてくれるらしい。これも試してみよう。

まずはコマンドのインストール。

$ go install golang.org/x/perf/cmd/benchstat@latest

先程のベンチマーク結果を benchstat コマンドに食わせてみる。

$ benchstat sample_sum_bench_v1.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
       │ sample_sum_bench_v1.txt │
       │         sec/op          │
Sum-12               32.41µ ± 6%

       │ sample_sum_bench_v1.txt │
       │          B/op           │
Sum-12                0.000 ± 0%

       │ sample_sum_bench_v1.txt │
       │        allocs/op        │
Sum-12                0.000 ± 0%

んー。 $6\,\%$ の分散はちょっと大きいかなぁ。『効率的なGo』によると，分散が $5\,\%$ 以上ある場合は環境ノイズ（バックグラウンドのプロセスとかメモリスワップとか）が大きい可能性があるらしい。まぁ，今回はこのまま進めよう。

benchstat で統計処理を行う場合は -count オプションを使って少なくとも6回以上は繰り返すべきと書かれている。これによって環境ノイズを検出しやすくなる。

benchstat コマンドは複数のベンチマーク結果を比較することもできる。

たとえば，先ほどの Sum() 関数のループ回数を半分にしたら速くなるだろうか。試してみよう。まず Sum() 関数を以下のように書き直す（ほとんど GitHub Copilot が書いたけどw）。

func Sum(data []int) int {
	total := 0
	l := len(data)
	h := l / 2
	for i := range h {
		total += data[i] + data[l-i-1]
	}
	if h*2 != l {
		total += data[h]
	}
	return total
}

これに対して先ほどと同じ条件でベンチマークテストを行う。

$ go test -run '^$' -bench '^BenchmarkSum$' -count 6 | tee sample_sum_bench_v2.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
BenchmarkSum-12    	   30920	     39051 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30186	     39492 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30282	     39615 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30373	     39535 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30525	     39413 ns/op	       0 B/op	       0 allocs/op
BenchmarkSum-12    	   30379	     39540 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	sample	7.215s

ありゃ。さっきより遅くなっちゃった？ benchstat コマンドで確認してみよう。

$ benchstat sample_sum_bench_v1.txt sample_sum_bench_v2.txt
goos: linux
goarch: amd64
pkg: sample
cpu: AMD Ryzen 5 PRO 4650G with Radeon Graphics
       │ sample_sum_bench_v1.txt │      sample_sum_bench_v2.txt       │
       │         sec/op          │   sec/op     vs base               │
Sum-12               32.41µ ± 6%   39.51µ ± 1%  +21.92% (p=0.002 n=6)

       │ sample_sum_bench_v1.txt │    sample_sum_bench_v2.txt    │
       │          B/op           │    B/op     vs base           │
Sum-12                0.000 ± 0%   0.000 ± 0%  ~ (p=1.000 n=6) ¹
¹ all samples are equal

       │ sample_sum_bench_v1.txt │    sample_sum_bench_v2.txt    │
       │        allocs/op        │ allocs/op   vs base           │
Sum-12                0.000 ± 0%   0.000 ± 0%  ~ (p=1.000 n=6) ¹
¹ all samples are equal

$22\,\%$ 近く遅くなっちゃったよ orz

p の値は統計的有意性を表す $p\,値$のことで，既定では $\alpha=0.05$ に設定されている（$\alpha$ の値は -alpha オプションで変更できる）。つまり p の値が 0.05 より小さければ有意な値であると見なすことができる。

それはともかく，とりあえずループ回数を畳み込むのはなしの方向で。

…てな感じで benchstat コマンドを使えば統計学や誤差論の知識がなくてもある程度の判断を下すことができる。

ブックマーク

More predictable benchmarking with testing.B.Loop - The Go Programming Language

参考図書

効率的なGo ―データ指向によるGoアプリケーションの性能最適化: Bartłomiej Płotka (著), 山口能迪 (翻訳); オライリー・ジャパン 2024-02-24; 単行本（ソフトカバー）; 4814400535 (ASIN), 9784814400539 (EAN), 4814400535 (ISBN); 評価

版元で Ebook を買える。Go言語のリファレンス本ではない。フトウェア工学，プログラミング（の考え方）を学ぶ教科書的な位置づけかなぁ。

reviewed by Spiegel on 2024-04-21 (powered by PA-APIv5)

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

実際に試してみたが10億回ループしてたので，やはり中身が消えてると思われる。ちなみにループ部分を for b.Loop() { ... } にしたら6億回のループになったので，多分そういうことなんだろう。 ↩︎
今回の記事のコードは testing パッケージのドキュメントにあるサンプルコードを参考にしている。 ↩︎
-run '^$' オプションはひとつもテストを実行しないことを示す。 -bench '^BenchmarkSum$' オプションは指定したベンチマークテストコードを実行することを示す。 -count 6 は指定したベンチマークテストを6回繰り返すことを示す。ベンチマークテストを繰り返すのは統計処理を行うため。 ↩︎

goroutine はグリーンスレッドではない（『Go言語で学ぶ並行プログラミング』読書会1回目）

2025-01-25T23:27:33+09:00

「しっぽのさきっちょ）」側の同名記事をこちらのセクションに移動しました。

「第1回『Go言語で学ぶ並行プログラミング』オンライン読書会」の話題より。

対象となる『Go言語で学ぶ並行プログラミング』は，版元から PDF 版を購入した。インプレス社って絶版でもないのにいつの間にか Kindle 版を引っ込めたりするそうで，デジタル版を買うなら PDF 版を買うのがオススメらしい。まぁ，技術参考書は PDF 版のほうが取り回ししやすいからな。紙はかさばるし。

事前にざっと斜め読みしたのだが，解説が丁寧という印象。タイトル通り Go 言語を前提に書かれているが C/C++ や Java などの構文型のプログラミング言語に慣れているのなら難しくないと思う。

まずは1章から順に読むのがおすすめ。「並行処理，完全に理解した」という人も復習のつもりで順に読んでいくのがいいだろう。

並行と並列

以前，読書感想文で『Go言語による並行処理』を大絶賛したのだが，その中の「2.1 並行性と並列性の違い」の中で

並行性はコードの性質を指し、並列性は動作しているプログラムの性質を指します。

『Go言語による並行処理』 p.23より

と書かれている。『Go言語で学ぶ並行プログラミング』では更に具体的に

並行性とは、多くのタスクを同時にどのように実行するかを計画する（planning）ことです。並列性とは、多くのタスクを同時に実行する（performing）ことです。

『Go言語で学ぶ並行プログラミング』 p.39より

と書かれている。たとえば

問. 「並行処理」と「並列処理」を使って文を書け

みたいな問題があったら

並行処理を組み込んだプログラムを書いて実行したところ正しく並列処理が行われた。

みたいに回答するのがいいだろうか（笑）

今回の読書会は第3章にかかった辺りまでだったが，今のところ『Go言語による並行処理』よりは『Go言語で学ぶ並行プログラミング』のほうがオススメな感じ。まぁ，あとから出た本だからねぇ。

goroutine はグリーンスレッドではない

並行処理の仕組みとしてカーネルが用意している機能にはプロセスとスレッドがある。

オペレーティングシステムの各プロセスは、他のプロセスから隔離された独自のメモリ空間を持っています。通常、プロセスは独立して動作し、他のプロセスとの相互作用は最小限です。プロセスは、多くの資源を消費する代償として、隔離を提供します。たとえば、あるプロセスがエラーでクラッシュしても、そのプロセスは独自のメモリ空間を持っているため、他のプロセスに影響を与えることはありません。この隔離の欠点は、多くのメモリを消費してしまうことです。さらに、メモリ領域やその他のシステム資源を確保する必要があるため、プロセスの起動には（スレッドに比べて）少し時間がかかります。

『Go言語で学ぶ並行プログラミング』 p.20より

新たなスレッドを作成する場合、オペレーティングシステムが作成する必要があるのは、スタック領域、レジスタ、プログラムカウンタを管理するのに十分な資源だけです。新たなスレッドは、同じプロセスのコンテキスト内で実行されます。対照的に、新たなプロセスを作成する場合、オペレーティングシステムはそれに完全に新たなメモリ空間を割り当てる必要があります。この理由から、スレッドはプロセスよりもはるかに軽量であり、システムが資源を使い果たすまでに、プロセスよりも多くのスレッドを作成することが通常可能です。さらに、新たに割り当てる資源がかなり少ないため、スレッドの起動はプロセスの起動よりもはるかに速いです。

[…]

ただし、この追加の性能には、ある代償が伴います。同じメモリ空間で作業するということは、プロセスが提供する隔離が得られないことを意味します。そのため、あるスレッドが他のスレッドの作業に干渉して被害を与える可能性があります。

『Go言語で学ぶ並行プログラミング』 p.25より

各スレッドがどの CPU コアに割り当てられるかはカーネルが決定する。このため上述のスレッドのことを特に「カーネルレベルスレッド」と呼ぶ。

カーネルレベルスレッドがあるということはユーザー空間で完全にアプリケーションが制御する「ユーザーレベルスレッド」もあるわけだ。

ユーザーレベルスレッドの主な利点は性能です。ユーザーレベルスレッドのコンテキストスイッチは、カーネルレベルスレッドのコンテキストスイッチよりも高速です。なぜなら、カーネルレベルのコンテキストスイッチでは、オペレーティングシステムが介入して次に実行するスレッドを選択する必要があるからです。カーネルを呼び出さずに実行を切り替えることができれば、実行中のプロセスは、キャッシュをフラッシュして処理速度を低下させる必要がなく、CPU を保持し続けられます。

ユーザーレベルスレッドを使うことの不都合な点は、ブロッキング I/O 呼び出しを行うコードを実行するときに現れます。ファイルからの読み込みが必要な状況を考えてみましょう。オペレーティングシステムはプロセスを 1 つの実行のスレッドと見なすため、ユーザーレベルスレッドがこのブロッキング読み込み呼び出しを実行すると、プロセス全体がスケジュールから外されます。同じプロセス内に他のユーザーレベルスレッドが存在する場合、読み込み操作が完了するまで、それらのスレッドは実行されません。

『Go言語で学ぶ並行プログラミング』 p.33-34より

で， Go の goroutine はどれやねん？という話だが，実はカーネルレベルスレッドとユーザーレベルスレッドを組み合わせたハイブリッドな構成となっている。

Go はハイブリッドシステムを採用することで、ユーザーレベルスレッドの優れた性能を提供し、不都合な点がほとんどありません。これは、カーネルレベルスレッドの集まりを使い、それぞれがゴルーチンのキューを管理することで実現しています。複数のカーネルレベルスレッドがあるので、複数のプロセッサが利用可能な場合、複数のプロセッサを利用できます。

『Go言語で学ぶ並行プログラミング』 p.34-35より

これを「M:N スレッディングモデル」と呼ぶ。

Go がゴルーチンに使っているシステムは、M:N スレッディングモデル（threading model）と呼ばれることがあります。M:N とするのは M 個のユーザーレベルスレッド（ゴルーチン）がN 個のカーネルレベルスレッドにマッピングされている場合です。これは、通常のユーザーレベルスレッドとは対照的です。通常のユーザーレベルスレッドは、N:1 スレッディングモデルと呼ばれ、1 つのカーネルレベルスレッドに対して N 個のユーザーレベルスレッドという意味です。M:N モデルのランタイムを実装するには、カーネルレベルスレッドの集まり上でユーザーレベルスレッドを移動させてバランスを取るための多くの技法が必要なため、他のモデルよりも複雑になります。

『Go言語で学ぶ並行プログラミング』 p.35より

一方で「グリーンスレッド」という言葉があるのだが，これは Java の用語らしい。

グリーンスレッド（green thread）という用語は、プログラミング言語 Java のバージョン 1.1で生まれました。Java のオリジナルのグリーンスレッドは、ユーザーレベルスレッドの実装でした。単一のコア上でのみ実行され、JVM によって完全に管理されていました。Javaバージョン 1.3 では、グリーンスレッドはカーネルレベルスレッドに取って代わられました。それ以来、多くの開発者がユーザーレベルスレッドの他の実装を指すために用語「グリーンスレッド」を使っています。後述するように、Go のランタイムはゴルーチンが複数の CPU を十分に活用できるようにしているので、 Go のゴルーチンをグリーンスレッドと呼ぶのはおそらく不正確です。

『Go言語で学ぶ並行プログラミング』 p.34より

へー。よその記事で goroutine をグリーンスレッドと書いてる気がするなぁ。直すの面倒だし，過去記事は放置で，これから気をつけることにしよう。

ちなみに Java 21 からは Go に似たスレッドモデルが正式に導入されていて，これは「仮想スレッド（virtual thread）」と呼ぶそうな。

Go のメモリモデル

翻訳者で読書会の主催者である柴田芳樹さんが今回おっしゃっていたが（実は訳者あとがきでも言及されている），『Go言語で学ぶ並行プログラミング』にはメモリモデルについての解説がない。並行処理とメモリ共有は密接な関係があるのでメモリモデルについても解説があればよかったのに，という感じ。

Go のメモリモデルについては公式のドキュメントがある。

The Go Memory Model - The Go Programming Language

このドキュメントの冒頭に

If you must read the rest of this document to understand the behavior of your program, you are being too clever.

via The Go Memory Model

とか皮肉（？）な文章が書かれていて笑っちまったよ。

それはともかく，中身をちょろんと紹介すると，たとえば

var a string

func f() {
    print(a)
}

func hello() {
    a = "hello, world"
    go f()
}

というコードがあったとき “hello, world” と出力されることが保証されるというもの。

The go statement that starts a new goroutine is synchronized before the start of the goroutine’s execution.

via The Go Memory Model

「当たり前やんけ！」と思うかもしれないが hello() 関数と f() 関数が異なる CPU コアで並列に実行される場合，この「保証」はかなり重要である。

マルチコアプロセッサでは（システムバスを通じて）メモリに直接アクセスするのではなく，メモリキャッシュを挟んだ間接的なアクセスになる。この際に複数の CPU コアとメモリとの間にデータ競合が起きないよう「キャッシュ・コヒーレンシー・プロトコル（cache-coherency protocols）」が走るらしい。

このプロトコルが正しく働いて CPU レベルでのデータ競合が起きないことが保証できないと，並行処理下で「何も信用できない」ことになってしまう。

キャッシュ・コヒーレンシー・プロトコル周りの話を始めるとそれだけで本が書けるそうで，実際に紹介してもらったが，かなりの分量があって理解するのも大変とのこと。たぶん『Go言語による並行処理』にメモリモデルの解説を入れると分量が1.5倍とか2倍とかになるんじゃないのかな（笑）

というわけで

次回以降の読書会も楽しみである。記事にするかどうかは不明。

ブックマーク

cutajarj/ConcurrentProgrammingWithGo: Listings from manning book : 『Go言語で学ぶ並行プログラミング』に出てくるサンプルコード

参考図書

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

へぇ～ボタン懐かし玩具リセットボタン: ノーブランド品; B0CX1NVW3F (ASIN)

へーへーへー

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go 1.22 における疑似乱数生成器

2024-03-07T22:20:40+09:00

Go 1.22 の math/rand パッケージと追加された math/rand/v2 パッケージを眺めている。

おそらく Go 1.22 における疑似乱数関連の最大のトピックは ChaCha8 がランタイムに組み込まれ，疑似乱数生成器の既定アルゴリズムになったことだろう。

The Salsa20 family of stream ciphers : これがベースになる論文かな
Salsa20 - Wikipedia
C2SP/chacha8rand.md at main · C2SP/C2SP · GitHub
つくって理解するストリーム暗号 ChaCha20 - ちりもつもればミルキーウェイ : Go でサンプルコードを書いておられる。ありがたや

ChaCha はストリーム暗号の一種で，簡単に言うと，疑似乱数を生成してそれを平文と XOR するというものらしい。このうちの疑似乱数を生成する部分を切り出しているようだ。ストリーム暗号に使うものなので，暗号技術的にセキュアでかつ速いというのが特徴になるだろうか。ちなみに ChaCha の後ろについている 20 とか 8 とかはラウンド数を示しているそうな。

ChaCha は OpenSSL だか OpenSSH だかでも見かけたような（うろ覚え）。もし結城浩さんが『暗号技術入門』の第4版を出される機会があれば，付録でいいので是非 ChaCha にも言及して欲しい。

ランタイムに ChaCha8 疑似乱数生成器を組み込む

ChaCha8 疑似乱数生成器のアルゴリズムは internal/chacha8rand パッケージに実装されている。中身については割愛させてもらう。 Internal パッケージなので，サードパーティのパッケージからは直接参照できない。

まずは runtime パッケージに組み込んでいる部分を見てみる。ちょっと長いけどご容赦。

// OS-specific startup can set startupRand if the OS passes
// random data to the process at startup time.
// For example Linux passes 16 bytes in the auxv vector.
var startupRand []byte

// globalRand holds the global random state.
// It is only used at startup and for creating new m's.
// Otherwise the per-m random state should be used
// by calling goodrand.
var globalRand struct {
    lock  mutex
    seed  [32]byte
    state chacha8rand.State
    init  bool
}

var readRandomFailed bool

// randinit initializes the global random state.
// It must be called before any use of grand.
func randinit() {
    lock(&globalRand.lock)
    if globalRand.init {
        fatal("randinit twice")
    }

    seed := &globalRand.seed
    if startupRand != nil {
        for i, c := range startupRand {
            seed[i%len(seed)] ^= c
        }
        clear(startupRand)
        startupRand = nil
    } else {
        if readRandom(seed[:]) != len(seed) {
            // readRandom should never fail, but if it does we'd rather
            // not make Go binaries completely unusable, so make up
            // some random data based on the current time.
            readRandomFailed = true
            readTimeRandom(seed[:])
        }
    }
    globalRand.state.Init(*seed)
    clear(seed[:])
    globalRand.init = true
    unlock(&globalRand.lock)
}

// readTimeRandom stretches any entropy in the current time
// into entropy the length of r and XORs it into r.
// This is a fallback for when readRandom does not read
// the full requested amount.
// Whatever entropy r already contained is preserved.
func readTimeRandom(r []byte) {
    // Inspired by wyrand.
    // An earlier version of this code used getg().m.procid as well,
    // but note that this is called so early in startup that procid
    // is not initialized yet.
    v := uint64(nanotime())
    for len(r) > 0 {
        v ^= 0xa0761d6478bd642f
        v *= 0xe7037ed1a0b428db
        size := 8
        if len(r) < 8 {
            size = len(r)
        }
        for i := 0; i < size; i++ {
            r[i] ^= byte(v >> (8 * i))
        }
        r = r[size:]
        v = v>>32 | v<<32
    }
}

via runtime/rand.go

これは疑似乱数生成器の状態（主に seed）を管理してる部分かな。最初の seed は乱数デバイスから取ってるんだね。これに失敗すると時刻から生成する，と。ユーザ側は明示的に seed を指定する必要がなくなるということやね。

// readTimeRandom stretches any entropy in the current time
// into entropy the length of r and XORs it into r.
// This is a fallback for when readRandom does not read
// the full requested amount.
// Whatever entropy r already contained is preserved.
func readTimeRandom(r []byte) {
    // Inspired by wyrand.
    // An earlier version of this code used getg().m.procid as well,
    // but note that this is called so early in startup that procid
    // is not initialized yet.
    v := uint64(nanotime())
    for len(r) > 0 {
        v ^= 0xa0761d6478bd642f
        v *= 0xe7037ed1a0b428db
        size := 8
        if len(r) < 8 {
            size = len(r)
        }
        for i := 0; i < size; i++ {
            r[i] ^= byte(v >> (8 * i))
        }
        r = r[size:]
        v = v>>32 | v<<32
    }
}

// bootstrapRand returns a random uint64 from the global random generator.
func bootstrapRand() uint64 {
    lock(&globalRand.lock)
    if !globalRand.init {
        fatal("randinit missed")
    }
    for {
        if x, ok := globalRand.state.Next(); ok {
            unlock(&globalRand.lock)
            return x
        }
        globalRand.state.Refill()
    }
}

// bootstrapRandReseed reseeds the bootstrap random number generator,
// clearing from memory any trace of previously returned random numbers.
func bootstrapRandReseed() {
    lock(&globalRand.lock)
    if !globalRand.init {
        fatal("randinit missed")
    }
    globalRand.state.Reseed()
    unlock(&globalRand.lock)
}

// rand32 is uint32(rand()), called from compiler-generated code.
//go:nosplit
func rand32() uint32 {
    return uint32(rand())
}

// rand returns a random uint64 from the per-m chacha8 state.
// Do not change signature: used via linkname from other packages.
//go:nosplit
//go:linkname rand
func rand() uint64 {
    // Note: We avoid acquirem here so that in the fast path
    // there is just a getg, an inlined c.Next, and a return.
    // The performance difference on a 16-core AMD is
    // 3.7ns/call this way versus 4.3ns/call with acquirem (+16%).
    mp := getg().m
    c := &mp.chacha8
    for {
        // Note: c.Next is marked nosplit,
        // so we don't need to use mp.locks
        // on the fast path, which is that the
        // first attempt succeeds.
        x, ok := c.Next()
        if ok {
            return x
        }
        mp.locks++ // hold m even though c.Refill may do stack split checks
        c.Refill()
        mp.locks--
    }
}

// mrandinit initializes the random state of an m.
func mrandinit(mp *m) {
    var seed [4]uint64
    for i := range seed {
        seed[i] = bootstrapRand()
    }
    bootstrapRandReseed() // erase key we just extracted
    mp.chacha8.Init64(seed)
    mp.cheaprand = rand()
}

via runtime/rand.go

mrandinit() 関数でランタイムを初期化して，それを使って実際に乱数を取得してるのが rand() 関数だね。ふむふむ。

math/rand パッケージのトップレベル関数群にランタイムの ChaCha8 を組み込む

それじゃあ math/rand パッケージの方を見てみよう。

//go:linkname runtime_rand runtime.rand
func runtime_rand() uint64

via math/rand/rand.go

go:linkname ディレクティブの説明は割愛する。こうやってリンクしてるということで飲み込んでいただければ（笑）そうそう。 go:linkname ディレクティブは unsafe パッケージを要求するので，真似するときは要注意だよ。

ともかく，この runtime_rand() 関数を使って rand.Source インタフェース互換の構造体 runtimeSource を定義している。

// runtimeSource is an implementation of Source64 that uses the runtime
// fastrand functions.
type runtimeSource struct {
    // The mutex is used to avoid race conditions in Read.
    mu sync.Mutex
}

func (*runtimeSource) Int63() int64 {
    return int64(runtime_rand() & rngMask)
}

func (*runtimeSource) Seed(int64) {
    panic("internal error: call to runtimeSource.Seed")
}

func (*runtimeSource) Uint64() uint64 {
    return runtime_rand()
}

via math/rand/rand.go

Seed() メソッドを呼び出したら panic 吐くとか容赦ないな（笑） runtimeSource はこんな風に使う。

// globalRandGenerator is the source of random numbers for the top-level
// convenience functions. When possible it uses the runtime fastrand64
// function to avoid locking. This is not possible if the user called Seed,
// either explicitly or implicitly via GODEBUG=randautoseed=0.
var globalRandGenerator atomic.Pointer[Rand]

var randautoseed = godebug.New("randautoseed")

// globalRand returns the generator to use for the top-level convenience
// functions.
func globalRand() *Rand {
    if r := globalRandGenerator.Load(); r != nil {
        return r
    }

    // This is the first call. Initialize based on GODEBUG.
    var r *Rand
    if randautoseed.Value() == "0" {
        randautoseed.IncNonDefault()
        r = New(new(lockedSource))
        r.Seed(1)
    } else {
        r = &Rand{
            src: &runtimeSource{},
            s64: &runtimeSource{},
        }
    }

    if !globalRandGenerator.CompareAndSwap(nil, r) {
        // Two different goroutines called some top-level
        // function at the same time. While the results in
        // that case are unpredictable, if we just use r here,
        // and we are using a seed, we will most likely return
        // the same value for both calls. That doesn't seem ideal.
        // Just use the first one to get in.
        return globalRandGenerator.Load()
    }

    return r
}

via math/rand/rand.go

// Seed uses the provided seed value to initialize the default Source to a
// deterministic state. Seed values that have the same remainder when
// divided by 2³¹-1 generate the same pseudo-random sequence.
// Seed, unlike the [Rand.Seed] method, is safe for concurrent use.
//
// If Seed is not called, the generator is seeded randomly at program startup.
//
// Prior to Go 1.20, the generator was seeded like Seed(1) at program startup.
// To force the old behavior, call Seed(1) at program startup.
// Alternately, set GODEBUG=randautoseed=0 in the environment
// before making any calls to functions in this package.
//
// Deprecated: As of Go 1.20 there is no reason to call Seed with
// a random value. Programs that call Seed with a known value to get
// a specific sequence of results should use New(NewSource(seed)) to
// obtain a local random generator.
func Seed(seed int64) {
    orig := globalRandGenerator.Load()

    // If we are already using a lockedSource, we can just re-seed it.
    if orig != nil {
        if _, ok := orig.src.(*lockedSource); ok {
            orig.Seed(seed)
            return
        }
    }

    // Otherwise either
    // 1) orig == nil, which is the normal case when Seed is the first
    // top-level function to be called, or
    // 2) orig is already a runtimeSource, in which case we need to change
    // to a lockedSource.
    // Either way we do the same thing.

    r := New(new(lockedSource))
    r.Seed(seed)

    if !globalRandGenerator.CompareAndSwap(orig, r) {
        // Something changed underfoot. Retry to be safe.
        Seed(seed)
    }
}

via math/rand/rand.go

つまり，環境変数 GODEBUG で明示的に指定（randautoseed=0）するか最初に rand.Seed() 関数を呼び出すかしない限りランタイムに組み込んだ ChaCha8 疑似乱数生成器が有効になるっちうわけだ。ちなみに lockedSource は math/rand パッケージに従来からある疑似乱数生成器で，名前の通り，ちゃんと mutex で排他処理している。

math/rand/v2 パッケージにおける Source インタフェースの定義

では，いよいよ Go 1.22 で追加された math/rand/v2 パッケージを見てみよう。

math/rand パッケージと math/rand/v2 パッケージとの大きな違いは rand.Source インタフェースが非互換になっていることだろう。

math/rand パッケージの Source インタフェースの定義は以下の通り。

// A Source represents a source of uniformly-distributed
// pseudo-random int64 values in the range [0, 1<<63).
//
// A Source is not safe for concurrent use by multiple goroutines.
type Source interface {
    Int63() int64
    Seed(seed int64)
}

// A Source64 is a [Source] that can also generate
// uniformly-distributed pseudo-random uint64 values in
// the range [0, 1<<64) directly.
// If a [Rand] r's underlying [Source] s implements Source64,
// then r.Uint64 returns the result of one call to s.Uint64
// instead of making two calls to s.Int63.
type Source64 interface {
    Source
    Uint64() uint64
}

via math/rand/rand.go

これに対して math/rand/v2 ではこう定義されている。

// A Source is a source of uniformly-distributed
// pseudo-random uint64 values in the range [0, 1<<64).
//
// A Source is not safe for concurrent use by multiple goroutines.
type Source interface {
    Uint64() uint64
}

via math/rand/v2/rand.go

どえらシンプル！ Seed() メソッドがなくなったのは大きいね。これによって runtimeSource やトップレベル関数群が参照する globalRand の定義もめっさシンプルになった。

// globalRand is the source of random numbers for the top-level
// convenience functions.
var globalRand = &Rand{src: &runtimeSource{}}

//go:linkname runtime_rand runtime.rand
func runtime_rand() uint64

// runtimeSource is a Source that uses the runtime fastrand functions.
type runtimeSource struct{}

func (*runtimeSource) Uint64() uint64 {
    return runtime_rand()
}

via math/rand/v2/rand.go

うんうん。シンプルが一番だね。

ChaCha8 を rand.Source にする

ChaCha8 疑似乱数生成器を疑似乱数の Source として明示的に組み込む場合は， rand.NewChaCha8() 関数を使って生成する。

import "internal/chacha8rand"

// A ChaCha8 is a ChaCha8-based cryptographically strong
// random number generator.
type ChaCha8 struct {
    state chacha8rand.State
}

// NewChaCha8 returns a new ChaCha8 seeded with the given seed.
func NewChaCha8(seed [32]byte) *ChaCha8 {
    c := new(ChaCha8)
    c.state.Init(seed)
    return c
}

// Seed resets the ChaCha8 to behave the same way as NewChaCha8(seed).
func (c *ChaCha8) Seed(seed [32]byte) {
    c.state.Init(seed)
}

// Uint64 returns a uniformly distributed random uint64 value.
func (c *ChaCha8) Uint64() uint64 {
    for {
        x, ok := c.state.Next()
        if ok {
            return x
        }
        c.state.Refill()
    }
}

via math/rand/v2/chacha8.go

ランタイムに組み込まれているものと違って，こちらは排他処理を行っていない。並行的に安全（concurrency safe）ではないわけだ。なので平行処理下で math/rand/v2 の ChaCha8 を扱う場合は要注意である。つか，平行処理下で ChaCha8 疑似乱数生成器を使うならトップレベル関数群を使うべきだろう。

PCG を rand.Source にする

math/rand/v2 にはもうひとつ疑似乱数生成器が用意されている。 PCG (Permuted Congruential Generator) というそうな。

// A PCG is a PCG generator with 128 bits of internal state.
// A zero PCG is equivalent to NewPCG(0, 0).
type PCG struct {
    hi uint64
    lo uint64
}

// NewPCG returns a new PCG seeded with the given values.
func NewPCG(seed1, seed2 uint64) *PCG {
    return &PCG{seed1, seed2}
}

via math/rand/v2/pcg.go

PCG は線形合同法（LCG）のバリエーションなんだそうで， LCG の統計学上の欠点を改善したものらしい。 2014年に発表された比較的新しいアルゴリズムのようだが，今のところは欠点のようなものは特に指摘されてないとか。当然ながら暗号技術分野では使えない。

こちらも並行的に安全ではないのでご注意を。

これから math/rand を使う理由はないかな

今までは math/rand で用意されている疑似乱数生成器は暗号技術的にセキュアではない（要件である「予測困難性」を満たさない）ため使いどころを考えなければならなかったが Go 1.22 から math/rand, math/rand/v2 ともに ChaCha8 が既定の疑似乱数生成器なったため用途を選ばずカジュアルに使えるようになるだろう。そうなると，これから疑似乱数生成器を使おうというとききに，わざわざ math/rand を使う理由はないかな。 math/rand って無駄に複雑になってる感じだもんなぁ。

ちなみに math/rand/v2 では Read() 関数もなくなっているが， math/rand でも rand.Read() 関数は Deprecated になってるし，リリースノートを見ると， Read() 関数が使いたきゃ crypto/rand パッケージを使え，みたいなことが書いてあるので，まぁそういうことなんだろう。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

効率的なGo ―データ指向によるGoアプリケーションの性能最適化: Bartłomiej Płotka (著), 山口能迪 (翻訳); オライリー・ジャパン 2024-02-24; 単行本（ソフトカバー）; 4814400535 (ASIN), 9784814400539 (EAN), 4814400535 (ISBN); 評価

版元で Ebook を買える。Go言語のリファレンス本ではない。フトウェア工学，プログラミング（の考え方）を学ぶ教科書的な位置づけかなぁ。

reviewed by Spiegel on 2024-04-21 (powered by PA-APIv5)

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

赤ずきんチャチャ 1 (りぼんマスコットコミックスDIGITAL): 彩花みん (著); 集英社 1993-02-15 (Release 2014-02-25); Kindle版; B00I8ETG96 (ASIN)

そういえばコミックは読んでないかな。「リボン」は読まなかったからなぁ...

プログラミング言語 Go [text.Baldanders.info]

Close 関数のエラーを無視しない（『効率的なGo』読書会より）

Close 関数のエラーを無視しない

最後まで読み切ってからクローズする

余談

参考図書

並行処理を待ち合わせる（WaitGroup と Barrier パターン）

タスクの完了を待ち合わせる

for ブロックのループ変数について

WaitGroup.Go メソッド

タスクの開始を待ち合わせる

ブックマーク

参考図書

struct2flag でコマンドライン解析【追記あり】

flag 標準パッケージによるコマンドライン解析

struct2flag でコマンドライン解析

【2025-10-18 追記】オプションの既定値を設定ファイルから取得する

【2025-10-18 追記】オプションの既定値を環境変数から取得する

【2025-10-19 追記】別解

ブックマーク

参考図書

“Philosophers” を Go で解く（CLI）

目次

コマンドライン・インタフェース

パラメータの定義

参考図書

“Philosophers” を Go で解く（問題編）

目次

基本ルール

パラメータおよび終了条件

その他 注意事項およびヒント

参考図書

『Go言語で学ぶ並行プログラミング』の練習問題より

参考図書

条件変数とセマフォ（『Go言語で学ぶ並行プログラミング』読書会3回目）

条件変数

書き込み優先な RWMutex

セマフォ

今回はここまで

ブックマーク

参考図書

Go 1.24 からのベンチマークテスト

ブックマーク

参考図書

goroutine はグリーンスレッドではない（『Go言語で学ぶ並行プログラミング』読書会1回目）

並行と並列

goroutine はグリーンスレッドではない

Go のメモリモデル

というわけで

ブックマーク

参考図書

Go 1.22 における疑似乱数生成器

ランタイムに ChaCha8 疑似乱数生成器を組み込む

math/rand パッケージのトップレベル関数群にランタイムの ChaCha8 を組み込む

math/rand/v2 パッケージにおける Source インタフェースの定義

ChaCha8 を rand.Source にする

PCG を rand.Source にする

これから math/rand を使う理由はないかな

ブックマーク

参考図書

その他注意事項およびヒント