List of Goroutine [text.Baldanders.info]

time.Ticker で遊ぶ【Go 1.16 バージョン】

2021-02-18T12:34:25+00:00

ずいぶん前に「time.Ticker で遊ぶ」と言う記事を書いたのだが，先日リリースされた Go 1.16 で signal.NotifyContext() 関数が追加された記念に，これを使った改訂版の記事を書いてみたいと思う。

前回と同じくお題は以下の通り。

一定周期ごとの処理を行う
Ctrl+C 等の割り込み処理を行う

一定周期ごとの処理を行う

これは前回の記事をほぼそのまま使いまわそう。

// +build run

package main

import (
    "fmt"
    "time"
)

func ticker() {
    t := time.NewTicker(1 * time.Second) //1秒周期の ticker
    defer func() {
        fmt.Println("Stopping ticker...")
        t.Stop()
    }()

    for {
        select {
        case now := <-t.C:
            fmt.Println(now.Format(time.RFC3339))
        }
    }
}

func main() {
    ticker()
}

前回でも説明した通り， defer 構文を使って終了時に time.Ticker.Stop() 関数で周期イベントを止めようとしているが，実際には無限ループなので return まで到達しない（笑）

NotifyContext 関数で SIGNAL を捕まえる

Go では SIGINT や SIGTERM といった OS から送信される SIGNAL をイベントとして channel に送り込む仕掛けがある（ちなみに Ctrl+C は SIGINT として送られる）。さらに Go 1.16 では SIGNAL イベントを context.Context のキャンセル・イベントとして実装できるようになった。

たとえば，こんな感じに書ける。

// +build run

package main

import (
    "context"
    "fmt"
    "os"
    "os/signal"
    "time"
)

func ticker(ctx context.Context) {
    t := time.NewTicker(1 * time.Second) //1秒周期の ticker
    defer func() {
        fmt.Println("Stopping ticker...")
        t.Stop()
    }()

    for {
        select {
        case now := <-t.C:
            fmt.Println(now.Format(time.RFC3339))
        case <-ctx.Done():
            fmt.Println("cancellation from context:", ctx.Err())
            return
        }
    }
}

func run() {
    ctx, _ := signal.NotifyContext(context.Background(), os.Interrupt)
    ticker(ctx)
}

func main() {
    run()
}

context パッケージは並行処理下で使うことが多いだろう。たとえば run() 関数をこんな感じに書き換えてみるか。

func run() {
    ctx, _ := signal.NotifyContext(context.Background(), os.Interrupt)
    var wg sync.WaitGroup
    for i := 0; i < 3; i++ {
        n := i + 1
        wg.Add(1)
        go func() {
            defer wg.Done()
            ticker(ctx, n)
        }()
    }
    wg.Wait()
}

これで平行に動作している全ての ticker() に対してキャンセルを送り込むことができる。

上のコード例ではひとつの context.Context インスタンスを複数の goroutine で使いまわしているが，以下のように

func run() {
    var wg sync.WaitGroup
    for i := 0; i < 3; i++ {
        n := i + 1
        wg.Add(1)
        go func() {
            defer wg.Done()
            ctx, _ := signal.NotifyContext(context.Background(), os.Interrupt)
            ticker(ctx, n)
        }()
    }
    wg.Wait()
}

各 goroutine ごとに context.Context インスタンスを生成してセットしても全ての ticker() を Ctrl+C で問題なく止めることができた。

キャンセル・イベントの伝搬

context パッケージは，名前の通り，異なるレイヤやドメイン間でコンテキスト情報を受け渡しするためのパッケージだが，親から子にキャンセルイベントが伝搬する性質がある（逆向きには伝搬しない）。たとえば

func run() {
    parent, _ := signal.NotifyContext(context.Background(), os.Interrupt)
    var wg sync.WaitGroup
    for i := 0; i < 3; i++ {
        n := i + 1
        wg.Add(1)
        go func() {
            defer wg.Done()
            child, _ := context.WithTimeout(parent, time.Duration(n)*5*time.Second)
            ticker(child, n)
        }()
    }
    wg.Wait()
}

などとすれば各 goroutine の ticker() 関数に SIGNAL イベントとタイムアウト・イベントの両方を仕込むことができる。

また

ctx, cancel := signal.NotifyContext(context.Background(), os.Interrupt)

とした場合の返り値の cancel は関数値になっていて，これをキックすることでペアとなっている context.Context インスタンス（上のコードなら ctx）にキャンセル・イベントを発生させることができる。実際の使い方として signal.NotifyContext() 関数は main goroutine に近いところで context.WithCancel() 関数と置き換えることが多いのではないだろうか。

context について詳しくは『Go 言語による並行処理』の 4.12 章が参考になる。素敵なキャンセル・ライフを（笑）

ブックマーク

Big Sky :: os/signal に NotifyContext が入った。

参考図書

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

[Comment] 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); 評価

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

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

Go の疑似乱数生成器は並行的に安全ではないらしい（追記あり）

2019-09-17T14:27:18+00:00

面白い記事みっけ！

【Go】rand.Sourceを並列で使いまわすなんて何事だ - Qiita

折角なので便乗記事を書いてみる。

まぁ，内部状態を持つオブジェクトは，状態が変わらない（immutable）か操作が並行的に安全（concurrency safe）であることが仕様・設計として明確であるものでない限り，複数の goroutine 間でインスタンスを共有してはいけない，というのは基本中の基本である。

ましてや標準の math/rand パッケージは rand.Source インタフェースを満たすのであればユーザ側で任意のアルゴリズムを用意することもできるので，並行的に安全であることを期待するほうが間違っているとも言える。

まずは，件の記事で書かれているコードを挙げておこう。ただし動作に直接関係ないコードは極力省いている。

package main

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

var randSource = NewRandSource()

func NewRandSource() *rand.Rand {
    return rand.New(rand.NewSource(time.Now().UnixNano()))
}

func calcRand() {
    for i := 0; i < 10000; i++ {
        randSource.Intn(1000)
    }
}

func main() {
    wg := sync.WaitGroup{}
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            calcRand()
            wg.Done()
        }()
    }
    wg.Wait()
}

ポイントは rand.Rand インスタンスを初期化時にひとつだけ生成し，複数の goroutine で使い回している点である。これを実行すると以下のように panic を吐く。

$ go run -trimpath sample.go
panic: runtime error: index out of range [-1]

goroutine 94 [running]:
math/rand.(*rngSource).Uint64(...)
    math/rand/rng.go:249
math/rand.(*rngSource).Int63(0xc000083500, 0x50321535775976c1)
    math/rand/rng.go:234 +0x93
math/rand.(*Rand).Int63(...)
    math/rand/rand.go:85
math/rand.(*Rand).Int31(...)
    math/rand/rand.go:99
math/rand.(*Rand).Int31n(0xc000088090, 0x3e8, 0x1fd)
    math/rand/rand.go:134 +0x5f
math/rand.(*Rand).Intn(0xc000088090, 0x3e8, 0x1fd)
    math/rand/rand.go:172 +0x45
main.calcRand()
    sample@/sample.go:17 +0x3f
main.main.func1(0xc000098000)
    sample@/sample.go:26 +0x22
created by main.main
    sample@/sample.go:25 +0x78
exit status 2

panic が発生する仕組みは件の記事に分かりやすく解説されているので参照のこと。

goroutine ごとにインスタンスを生成する

件の記事では解決方法が（具体的には）示されていないので，こちらでいくつか考えてみよう。

一番簡単なのは goroutine ごとに rand.Rand インスタンスを生成することだ。こんな感じに変えたらどうだろう。

func calcRand(rnd* rand.Rand) {
    for i := 0; i < 10000; i++ {
        rnd.Intn(1000)
    }
}

func main() {
    wg := sync.WaitGroup{}
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            calcRand(NewRandSource())
            wg.Done()
        }()
    }
    wg.Wait()
}

これで必要十分に機能するし，少なくとも panic は起こらない。このやり方の欠点は（goroutine ごとに rand.Rand インスタンスが生成されるため）元のコードより（僅かだが）高コストになることと，疑似乱数生成器の性能がアルゴリズムだけでなく seed の選び方にも依存する，というあたりだろうか。

まぁ math/rand の標準アルゴリズム¹ であれば性能に関してはさしたる問題にはならないだろう。

Generator Pattern を使う

今回の例ではあまりオススメではないのだが，並行処理の Generator Pattern を使う手もある。

まず NewRandSource() 関数を以下の関数で置き換える。

func NewGenerator() <-chan int {
    rnd := rand.New(rand.NewSource(time.Now().UnixNano()))
    ch := make(chan int)
    go func() {
        defer close(ch)
        for {
            ch <- rnd.Intn(1000)
        }
    }()
    return ch
}

こうすれば rand.Rand インスタンスはひとつで済むし（seed もひとつ），持ち回すインスタンスは channel のみなので並行的に安全にできる。乱数の取り出し側はこう書き換えればよい。

func calcRand(gen <-chan int) {
    for i := 0; i < 10000; i++ {
        if _ , ok := <-gen; !ok {
            return
        }
    }
}

func main() {
    wg := sync.WaitGroup{}
    gen := NewGenerator()
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            calcRand(gen)
            wg.Done()
        }()
    }
    wg.Wait()
}

このコードの欠点は「遅い」ことに尽きる。まぁ channel の読み書きで同期を取る必要があるから遅くなって当たり前だけど。

今回のようなケースではなく，例えば generator がハードウェア制御を伴うものだったり singleton を含む処理だったり channel の読み書きにかかるコストに対して他の処理が相対的に大きくなったり …などなど，状況によっては Generator Pattern のほうが有利になる場合もあるだろう。

Generator Pattern は平行処理のデザインパターンの中では比較的単純なものだが応用範囲が広い。 Go 言語の goroutine 自体は（OS スレッドなどと比べて）かなり安価で手軽に構成できるので，積極的に試してみるといいと思う。

おまけの追記

そうそう。上の NewGenerator() 関数で生成・駆動される goroutine は自力で終了できない。なので，以下のように

func NewGenerator(ctx context.Context) <-chan int {
    rnd := rand.New(rand.NewSource(time.Now().UnixNano()))
    ch := make(chan int)
    go func() {
        defer close(ch)
        for {
            select {
            case <-ctx.Done():
                return
            default:
                ch <- rnd.Intn(1000)
            }
        }
    }()
    return ch
}

外部からキャンセルイベントを流し込めるようにするといいかもしれない。

【2019-09-20 追記】実は標準で並行的に安全な疑似乱数生成器が用意されていた

あれから math/rand のソースコードを眺めてて気がついたのだが，実は並行的に安全な疑似乱数生成器が標準で用意されていた。

たとえば rand.Intn() 関数を見ると

// Intn returns, as an int, a non-negative pseudo-random number in [0,n)
// from the default Source.
// It panics if n <= 0.
func Intn(n int) int { return globalRand.Intn(n) }

とか書かれていて，じゃあ globalRand って何なん？と思って見てみたら

type lockedSource struct {
	lk  sync.Mutex
	src Source64
}


func (r *lockedSource) Int63() (n int64) {
	r.lk.Lock()
	n = r.src.Int63()
	r.lk.Unlock()
	return
}

func (r *lockedSource) Uint64() (n uint64) {
	r.lk.Lock()
	n = r.src.Uint64()
	r.lk.Unlock()
	return
}

func (r *lockedSource) Seed(seed int64) {
	r.lk.Lock()
	r.src.Seed(seed)
	r.lk.Unlock()
}

...

var globalRand = New(&lockedSource{src: NewSource(1).(Source64)})

とか書かれているわけですよ。なんだ，ちゃんと sync.Mutex で排他制御してるんぢゃん。

というわけで，最初のコードは

package main

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

func calcRnad() {
	for i := 0; i < 10000; i++ {
		rand.Intn(1000)
	}
}

func main() {
	rand.Seed(time.Now().UnixNano())
	wg := sync.WaitGroup{}
	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			calcRnad()
			wg.Done()
		}()
	}
	wg.Wait()
}

と書けば panic を吐くことなくちゃんと終了する。若干遅くはなるけど，それでも Generator Pattern を使うよりは全然速い。

ブックマーク

参考図書

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

[Comment] 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)

math/rand パッケージに実装されている擬似乱数生成器はラグ付フィボナッチ法（Lagged Fibonacci Generator）のバリエーションらしい。 ↩︎

『Go 言語による並行処理』は Go 言語プログラマ必読書だろう

2018-11-03T00:50:43+00:00

やぁ！ついに “Concurrency in Go” の邦訳版が登場したですよ。めでたい！

Go 言語の特徴はいくつかあるが，大きなものとして「並行処理¹」を前提とした言語設計が挙げられる。

並行処理では CSP (Communicating Sequential Processes) の成果が取り入れられている。これが goroutine と channel である。

Goroutine は軽量スレッドなどと呼ばれることもあるが²，厳密には coroutine の一種である。 Main goroutine を含む各 goroutine はランタイム・プログラムに組み込まれたスケジューラによって制御される。つまり実行時の並列処理の詳細はコードレベルでは隠蔽されているのだ。故にプログラマはコード上の並行処理にのみ注力して記述すればいいことになる。 OS スレッドの仕様がどうなってるとか無駄にデカいスレッドをプールの中でどう使い回すかとか，生産性の欠片もないようなことは考えなくていいわけだ³。

Channel は入出力プリミティブで，これによって goroutine 間のメッセージ・パッシング（message passing）を実現している。たとえば以下のような感じで記述する⁴。

package main

import "fmt"

//main goroutine
func main() {
    hello := make(chan interface{}) //create channel
    go func() { //sub goroutine
        hello <- "Hello, world!" //send
    }()
    fmt.Println(<-hello) //receive
}

（go 構文（go statement）でキックされた関数が sub goroutine となる。関数閉包（closure）になっている点に注目）

これらに加えて，同期をとるための sync パッケージやコールグラフの各枝をキャンセルするための context パッケージが標準ライブラリで用意されている。

メッセージ・パッシングを構成するか sync パッケージ等を用いて legacy なメモリアクセス同期を構成するか（あるいはそれらを組み合わせるか）の判断は難しいが，2.4章に大まかな指針が挙げられているので参考になるだろう。ただし，今まで無理やりメモリアクセス同期で運用していたもののうちかなりのものを軽くて（スレッドセーフという意味で）安全なメッセージ・パッシングに置き換えられるのは確かである。

そうそう。『Go 言語による並行処理』では context パッケージについてページを割いて紹介されているのだ⁵（4.12章）。 context パッケージをデザイン・パターンとして日本語できちんと紹介している Web 記事や書籍はあまり見かけないので，単純に嬉しい。

並行処理プログラミングが難しいのは，デザイン・パターン（4章で言及されている）の熟成がまだ若いこと，パターンの組み合わせ最適化が複雑なこと，もっと言うなら並行処理の設計は context driven であること，にあると思う（だからこそ context パッケージは秀逸なのよ）。デザイン・パターンは（数学の公式と同じく）思考のショートカットなので，そのパターンを構成することの意味を分かった上で適用しないと失敗することが多いんじゃないだろうか。

この本を読んで「よっしゃ，明日から立派な goroutine 使いだ！」とはならないと思うけど，有象無象なコピペ・プログラマじゃなく，きちんと Go 言語のプログラミングを勉強したいのであれば，この本は必読書になると思う。少なくとも（立ち読みででも）2章までは熟読すべき。

ところで余談だが，補遺Bは日本語版オリジナルの章だそうだけど，その中に Go 2 ドラフトで提案されている Generics についてしれっと書かれている。

Go 2 Drafts Announcement - YouTubeより

次期 Go 言語に搭載される（かもしれない） Generics についての解説は以下を参考にどうぞ。

Go 2のgenerics/contract簡易まとめ

ブックマーク

参考図書

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

[Comment] 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)

「同時に複数の動作が行われていること」を意味する言葉として「並行（concurrent）」と「並列（parallel）」が混同されることがあるが，プログラミングにおいては，書かれたコードの性質をを表すものを「並行」，動作するランタイム・プログラム（群）の性質を表すものを「並列」と呼んで区別している。両者は密接に関連しているが等価ではない。 ↩︎
OS スレッドに比べて goroutine を駆動する（ランタイム・プログラムが展開する）グリーン・スレッドは非常に軽量らしい。初期のメモリ割当で数キロバイト程度で，実行時に自動的に増減するようだ。 Goroutine のリソースの概算については3.1章で言及されている。 ↩︎
ある規模以上のシステムの場合は流量制限等をかける必要があるかも知れない。大規模システム開発での注意点については5章で言及されている。 ↩︎
受信（<-chan）は単項演算子で，送信（chan<-）は送信構文（send statement）で記述する。 ↩︎
context パッケージはバージョン 1.7 から標準ライブラリに組み込まれたため，古い参考書には載っていない。なお context パッケージにはキャンセルの伝搬以外にもコールグラフ間でデータを受け渡す機能もある。もっともこちらは濫用するとヤバいけど。 ↩︎

time.Ticker で遊ぶ

2018-03-01T11:28:49+00:00

【2021-02-18】 Go 1.16 で追加された関数を使った「time.Ticker で遊ぶ【Go 1.16 バージョン】」を公開した。併せてどうぞ。

相変わらず小ネタで。今回の目標は2つ。

一定周期ごとの処理を行う
Ctrl+C 等の割り込み処理を行う

一定周期ごとの処理を行う

Go 言語で一定周期ごとに処理を行うには time.Ticker が使える。以下は1秒ごとに現在時刻を表示する処理である。

package main

import (
	"fmt"
	"time"
)

func ticker() {
	t := time.NewTicker(1 * time.Second) //1秒周期の ticker
	defer t.Stop()

	for {
		select {
		case now := <-t.C:
			fmt.Println(now.Format(time.RFC3339))
		}
	}
}

func main() {
	ticker()
}

time.Ticker.C は受信 channel で，周期イベント発生時の時刻がセットされる。 defer 構文を使って終了時に time.Ticker.Stop() 関数で周期イベントを止めようとしているが，実際には無限ループなので， return まで到達しない（笑）

このコードはちゃんと動くが，終了条件を記述していないので Ctrl+C などで外部から強制的に止めない限り動き続ける。

SIGNAL を捕まえる

Go 言語では SIGINT や SIGTERM といった OS から送信される SIGNAL をイベントとして channel に送り込む仕掛けがある（ちなみに Ctrl+C は SIGINT として送られる）。この仕掛けを組み込んだコードが以下である。

package main

import (
	"fmt"
	"os"
	"os/signal"
	"syscall"
	"time"
)

func ticker() {
	t := time.NewTicker(1 * time.Second) //1秒周期の ticker
	defer t.Stop()

	sig := make(chan os.Signal, 1)
	signal.Notify(sig,
		syscall.SIGHUP,
		syscall.SIGINT,
		syscall.SIGTERM,
		syscall.SIGQUIT,
	)
    defer signal.Stop(sig)

	for {
		select {
		case now := <-t.C:
			fmt.Println(now.Format(time.RFC3339))
		case s := <-sig:
			switch s {
			case syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT:
				fmt.Println("Stop!")
				return
			}
		}
	}
}

func main() {
	ticker()
}

このやり方であれば Ctrl+C でも強制終了することなく正しく time.Ticker.Stop() 関数が起動される。

ここまでが main goroutine のみの処理の場合。複数の goroutine が協調して動いている場合は SIGNAL イベントに対して全ての goroutine が適切に処理を行う必要がある。

キャンセル・イベントの伝搬

Go 言語 1.7 から context が標準パッケージに加わった。 context パッケージは，名前の通り，異なるレイヤやドメイン間でコンテキスト情報を受け渡しするためのパッケージだが，キャンセル・イベントを扱うことができる。

ctx := context.Background()
parent, cancelParent := context.WithCancel(ctx)
child, cancelChild := context.WithCancel(parent)

cancelParent および cancelChild は関数値で，これをキックすることでそれぞれの context.Context にキャンセル・イベントが発生する。面白いのは parent で発生したイベントは child にも伝搬する点である（逆向きには伝搬しない）。これを利用して，発生した SIGNAL に対して親の context.Context にイベントを発生させることによって全ての子 context.Context にイベントを伝搬させることが可能になる。

たとえば，先ほどの SIGNAL の処理は以下のように書き直すことができる。

func SignalContext(ctx context.Context) context.Context {
	parent, cancelParent := context.WithCancel(ctx)
	go func() {
		defer cancelParent()

		sig := make(chan os.Signal, 1)
		signal.Notify(sig,
			syscall.SIGHUP,
			syscall.SIGINT,
			syscall.SIGTERM,
			syscall.SIGQUIT,
		)
        defer signal.Stop(sig)

		select {
		case <-parent.Done():
			fmt.Println("Cancel from parent")
			return
		case s := <-sig:
			switch s {
			case syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT:
				fmt.Println("Stop!")
				return
			}
		}
	}()

	return parent
}

ticker() 関数のほうも context.Context のイベントを拾えるよう以下のように書き直す。

func ticker(ctx context.Context) error {
	t := time.NewTicker(1 * time.Second) //1秒周期の ticker
	defer t.Stop()

	for {
		select {
		case now := <-t.C:
			fmt.Println(now.Format(time.RFC3339))
		case <-ctx.Done():
			fmt.Println("Stop child")
			return ctx.Err()
		}
	}
}

周期処理と SIGNAL 受信処理を別々の goroutine で駆動させて両者を context.Context で繋ぐのである。

完全なコードは以下の通り。

package main

import (
	"context"
	"fmt"
	"os"
	"os/signal"
	"syscall"
	"time"
)

func ticker(ctx context.Context) error {
	t := time.NewTicker(1 * time.Second) //1秒周期の ticker
	defer t.Stop()

	for {
		select {
		case now := <-t.C:
			fmt.Println(now.Format(time.RFC3339))
		case <-ctx.Done():
			fmt.Println("Stop child")
			return ctx.Err()
		}
	}
}

func SignalContext(ctx context.Context) context.Context {
	parent, cancelParent := context.WithCancel(ctx)
	go func() {
		defer cancelParent()

		sig := make(chan os.Signal, 1)
		signal.Notify(sig,
			syscall.SIGHUP,
			syscall.SIGINT,
			syscall.SIGTERM,
			syscall.SIGQUIT,
		)
        defer signal.Stop(sig)

		select {
		case <-parent.Done():
			fmt.Println("Cancel from parent")
			return
		case s := <-sig:
			switch s {
			case syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT:
				fmt.Println("Stop!")
				return
			}
		}
	}()

	return parent
}

func Run(ctx context.Context) error {
	errCh := make(chan error, 1)
	defer close(errCh)

	parent := SignalContext(ctx)
	go func() {
		child, cancelChild := context.WithTimeout(parent, 10*time.Second)
		defer cancelChild()
		errCh <- ticker(child)
	}()

	err := <-errCh
	fmt.Println("Done parent")
	return err
}

func main() {
	ctx := context.Background()
	if err := Run(ctx); err != nil {
		fmt.Fprintln(os.Stderr, err)
		return
	}
	fmt.Println("Done")
}

ちなみに context.WithTimeout() 関数は context.Context にタイムアウト・イベントを付加する。他にもデッドライン日時を指定する context.WithDeadline() 関数がある。

なんか今回は久しぶりに Go 言語っぽいコードだったねぇ（笑）

【追記】 Windows では SIGNAL を送信できない

今回は SIGNAL を受信する場合の話だったが，もちろん任意のプロセスに SIGNAL を送信することもできる。以下は自分自身に SIGINT を投げるコード例である¹。

proc, _ := os.FindProcess(os.Getppid())
proc.Signal(os.Interrupt)

ただし，このコードは Windows では（コンパイル・エラーにはならないが）動かない。 Windows 用の os.Process.Signal() 関数の実体は以下の通りだが

func (p *Process) signal(sig Signal) error {
	handle := atomic.LoadUintptr(&p.handle)
	if handle == uintptr(syscall.InvalidHandle) {
		return syscall.EINVAL
	}
	if p.done() {
		return errors.New("os: process already finished")
	}
	if sig == Kill {
		err := terminateProcess(p.Pid, 1)
		runtime.KeepAlive(p)
		return err
	}
	// TODO(rsc): Handle Interrupt too?
	return syscall.Errno(syscall.EWINDOWS)
}

このように os.Kill (SIGKILL) 以外は効かないようになっている。理由は不明だが TODO になってるようなので何か理由があるのだろう。

というわけでテストができないのですよ orz

ブックマーク

参考図書

プログラミング言語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)

syscall パッケージを使うやり方もあるが，今回は割愛する。つか， Windows 版には syscall.Kill() 関数が存在しないのでやりようがないのだが。 ↩︎

Go 言語における Singleton Pattern

2017-10-24T05:43:01+00:00

今回は小ネタでお送りします。

いや，ネットでね，Go 言語での Singleton 実装をこんな感じに書く人をやたら見かけるのだが

//Hello class
type Hello struct{}

var instance *Hello

//GetInstance returns singleton instance
func GetInstance() *Hello {
    if instance == nil {
        instance = &Hello{}
    }
    return instance
}

はっきり言って Singleton なめんな！ ですよ。

そうそう。プログラマで Singleton Pattern を知らない人はいないと思うけど，一応解説しておくと， Singleton Pattern というのは，あるクラスに対してプログラム全体でインスタンスがひとつだけ生成されるよう制限するプログラミング・パターンである。たとえば，単一セッションでシリアルに通信を行う entity class なんかはインスタンスがぼこぼこできて各々勝手に処理をされると困るわけで¹， singleton インスタンスの内部で同期をとっていく必要があるわけ。

という説明からも分かると思うけど「スレッドセーフでない singleton 実装に存在意義はない」のである。ちなみに結城浩さんのデザパタ本にあるサンプルコードも以下のようになっている（こっちは Java での記述だけど²）。

import java.util.Date;

public class MySystem {
    private static MySystem instance = null;
    private Date date = new Date();
    private MySystem() {
    }
    public Date getDate() {
        return date;
    }
    public static synchronized MySystem getInstance() {
        if (instance == null) {
            instance = new MySystem();
        }
        return instance;
    }
}

static で synchronized なのがポイントね。つまり，実際にインスタンスを生成する処理では何らかの手段でスレッドセーフであることが保証されてないといけない³。最初の Go 言語のパターンが何故ダメなのかは実際に動くコードを書いてみれば分かる。

package main

import (
    "fmt"
    "time"
)

//Hello class
type Hello struct{}

func (h *Hello) String() string {
    return "Hello"
}

var instance *Hello

//GetInstance returns singleton instance
func GetInstance() *Hello {
    if instance == nil {
        fmt.Println("new instance")
        time.Sleep(1 * time.Second) //delay 1sec
        instance = &Hello{}
    }
    return instance
}

func main() {
    ch := make(chan interface{})
    go run(ch, "Alice")
    go run(ch, "Bob")
    go run(ch, "Chris")
    <-ch
    <-ch
    <-ch
}

func run(ch chan<- interface{}, person string) {
    hello := GetInstance()
    ch <- hello //blocking
    fmt.Println(hello, person)
}

簡単に説明すると，まず GetInstance() 関数内部で初期化処理時間を演出するために１秒間の delay を発生させている。 run() 関数内で channel ch にインスタンスを食わせているのはブロッキングのため。別に何を食わせてもいいのだが，手近に GetInstance() 関数で取得したインスタンスがあるので，それを食わせている。 main() 関数では run() 関数を goroutine で3連続起動したあと， <-ch でブロックを解除している。

実行結果は以下の通り。

new instance
new instance
new instance
Hello Alice
Hello Chris
Hello Bob

並行処理下の3つの run() 関数に対してインスタンスが3つ生成されてしまっているのが分かると思う。

ではどう書けばいいのか。一番簡単なのは var 宣言時に初期化してしまうことである。

var instance = &Hello{}

//GetInstance returns singleton instance
func GetInstance() *Hello {
    return instance
}

次に簡単なのは init() 関数を使うことである。

var instance *Hello

func init() {
    //create instance and initialize
    instance = &Hello{}
}

init() 関数は少し特殊な関数で，main() 関数がキックされる前，パッケージ内の var 宣言時の初期化の後に呼ばれる。ひとつのパッケージ内またはひとつのファイル内にいくつも init() 関数を設置できるのが特徴なのだが，どういう順番に起動するかは言語仕様として明記されていないため⁴，パッケージ内の複数の init() 関数同士が依存また干渉するような書き方は避けるべきだろう。

main() 関数がキックされるまではメイン以外の goroutine は（生成は可能だが）起動されないことが保証されているため，記述がスレッドセーフか否か気にする必要はない。言い方を変えると，何らかの同期を伴う初期化処理の場合はこの方法では記述できないことになる。

「どうしても GetInstance() 関数内で同期をとりたいんじゃ」という場合は… たとえば sync パッケージを使うとかだろうか。 Singleton Pattern におあつらえ向きの sync.Once というのがある。最初に挙げた例を流用するならこんな感じだろうか。

//Hello class
type Hello struct{}

var instance * Hello
var once sync.Once

//GetInstance returns singleton instance
func GetInstance() * Hello {
    once.Do(func() {
        instance = &Hello{}
    })
    return instance
}

以下のコードで実際に動かして検証してみよう。

package main

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

//Hello class
type Hello struct{}

func (h * Hello) String() string {
    return "Hello"
}

var instance * Hello
var once sync.Once

//GetInstance returns singleton instance
func GetInstance() * Hello {
    once.Do(func() {
        fmt.Println("new instance")
        time.Sleep(1 * time.Second) //delay 1sec
        instance = &Hello{}
    })
    return instance
}

func main() {
    ch := make(chan interface{})
    go run(ch, "Alice")
    go run(ch, "Bob")
    go run(ch, "Chris")
    <-ch
    <-ch
    <-ch
}

func run(ch chan<- interface{}, person string) {
    hello := GetInstance()
    ch <- hello //blocking
    fmt.Println(hello, person)
}

実行結果は以下の通り。

new instance
Hello Chris
Hello Alice
Hello Bob

ちゃんと singleton として動作していることが分かる。

ブックマーク

参考図書

プログラミング言語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)

Java言語で学ぶリファクタリング入門: 結城浩 (著); SBクリエイティブ 2007-01-26 (Release 2014-03-12); Kindle版; B00I8AT1EU (ASIN); 評価

[Comment] 結城浩さんによる「リファクタリング本」の Kindle 版。意外にも Java 以外でも応用できる優れもの。

reviewed by Spiegel on 2018-12-11 (powered by PA-APIv5)

増補改訂版 Java言語で学ぶデザインパターン入門マルチスレッド編: 結城浩 (著); SBクリエイティブ 2004-06-18 (Release 2014-03-12); Kindle版; B00I8AT1BS (ASIN); 評価

[Comment] 結城浩さんによる通称「デザパタ本」の Kindle 版。意外にも Java 以外でも応用できる優れもの。

reviewed by Spiegel on 2018-12-07 (powered by PA-APIv5)

HTTP なんかはステートレスでパラレルにやり取りできるため Singleton Pattern は不要。ちなみに goroutine 間の通信は channel を使えっちう話です，はい。 ↩︎
このコードのパターンは Singleton Pattern を説明するにはよく出来ているしちゃんと動く（ココ重要）が，同期コストが高いため，実際にはあまり使われない。 Java における Singleton Pattern には様々な実装例があるので探してみるといいだろう。ちなみに Java 使いではなくとも結城浩さんのデザパタ本は買って読んでおくことを強くお勧めする。 Java 使いの方から見ると古いバージョンで書かれたコードなのが難点だが，紙の本で買うとサンプルコード入りのディスクが付いてくるので若干お得？ ↩︎
他にもインスタンスのコピー（コピーコンストラクタ等）を暗黙的に許容する言語ではコピーを無効にする措置が必要，とかある。そういう意味じゃ今回私が書いたコードも不完全で，実際には singleton インスタンスを隠蔽するためのラッパークラスが必要になる。ビジネス・ロジックも含めると，実は Singleton の実装ってそう甘くないのよねー ↩︎
どうもソースファイルのファイル名が影響するらしい。つまりファイル名を工夫すれば init() 関数の呼び出し順を制御できる，という噂。 ↩︎

「ズンドコチェック」なるものが流行っているらしい

2016-03-12T13:12:53+00:00

Javaの講義、試験が「自作関数を作り記述しなさい」って問題だったから
「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ！」って出力した後終了って関数作ったら満点で単位貰ってた
— てくも (@kumiromilk) 2016年3月9日

「習作（study）」としてはなかなか秀逸なアイデアだと思う。これで満点くれる教官も流石だが（笑）巷では「ズンドコキヨシ」とか「キヨシチェック」とか「ズンドコチェック」とか呼ばれているらしい。

というわけで

「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ！」って出力した後終了って関数

を Go 言語で実装することを考えてみる。私はコレを「ズンドコ・コール（zundoko-choir）」と呼ぶことにする。

とはいえ，ズンドコ・コールを実装する事自体はそう難しくない。たとえばこんな感じ。

package main

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

const (
    zun     = "ズン"
    doko    = "ドコ"
    kiyoshi = "キ・ヨ・シ！"
)

func generate() chan string {
    ch := make(chan string)
    go func() {
        var zundoko = [2]string{zun, doko}
        rand.Seed(time.Now().UnixNano())
        for {
            ch <- zundoko[rand.Intn(2)]
        }
    }()
    return ch
}

func main() {
    zundoko := generate()
    zcount := 0
    for {
        zd := <-zundoko
        fmt.Print(zd)
        if zd == zun {
            zcount++
        } else if zcount >= 4 {
            break
        } else {
            zcount = 0
        }
    }
    fmt.Print(kiyoshi)
}

「ズン」および「ドコ」をランダムに生成する部分は channel と goroutine を使えばいいだろう（generate() 関数内の処理）。擬似乱数は厳密でなくてもいいので安直に math/rand を使うことにした¹。さらに「ズン」「ズン」「ズン」「ズン」「ドコ」の配列パターンのチェックだが，「ズン」が4回以上連続で来た直後に「ドコ」が来たら OK としてみた。まぁ，これがもっとも素朴な実装でパフォーマンスとしてもそれほど遜色ない筈。

と，ここまで考えてハタと気づいた。問題は「自作関数を作り記述しなさい」なんだからメイン関数にロジック書いたらアカンやん！

というわけでまたもゴリゴリとコードを書いてパッケージにしてしまった。アホだ，私（笑）

spiegel-im-spiegel/zundoko: Zundoko-choirs

出力は標準出力に直書きするのではなく string の slice に append() することで実現する。この出力先を Choirs 型として定義した。

//Choirs - zundoko-choirs list
type Choirs struct {
    c []string
}

//Push is append choirs
func (c *Choirs) Push(s string) {
    c.c = append(c.c, s) //maybe panic if c is nil.
}

func (c *Choirs) String() string {
    if c == nil {
        return ""
    }
    content := make([]byte, 0, 128)
    for _, s := range c.c {
        content = append(content, s...)
    }
    return string(content)
}

ちなみに文字列の連結は strings.Join() 関数は使わず「文字列連結はどれが速い？」で紹介した方法を使っている。

これで最初のコードは

func generate() chan string {
    ch := make(chan string)
    go func() {
        var zd = [2]string{Zun, Doko}
        rand.Seed(time.Now().UnixNano())
        for {
            ch <- zd[rand.Intn(2)]
        }
    }()
    return ch
}

//Run zundoko-choirs
func Run() *Choirs {
    zd := generate()
    c := &Choirs{make([]string, 0)}
    zcount := 0
    for {
        s := <-zd
        c.Push(s)
        if s == Zun {
            zcount++
        } else if zcount >= 4 {
            break
        } else {
            zcount = 0
        }
    }
    c.Push(Kiyoshi)
    return c
}

と書き換えることができる。このパッケージを呼び出すメイン側は例えば

package main

import (
    "fmt"

    "github.com/spiegel-im-spiegel/zundoko"
)

func main() {
    c := zundoko.Run()
    fmt.Println(c)
}

と書けばいい。

ところで「ズン」「ドコ」の出力は Choirs 型で保持られているので，末尾の5要素のパターンを調べる別の方法もあると気づく。たとえばこんな感じ。

var matchingPattern = []string{Zun, Zun, Zun, Zun, Doko}

func (c *Choirs) match() bool {
    if c == nil {
        return false
    }
    if len(c.c) < 5 {
        return false
    }
    return reflect.DeepEqual(c.c[len(c.c)-5:], matchingPattern)
}

この関数を使えば Run() 関数は

//Run2 zundoko-choirs (another logic)
func Run2() *Choirs {
    zd := generate()
    c := &Choirs{make([]string, 0)}
    for {
        s := <-zd
        c.Push(s)
        if c.match() {
            break
        }
    }
    c.Push(Kiyoshi)
    return c
}

となり随分すっきりする。ただこれコストが高くつきそうである。というわけで，これも調べてみた。まず以下のベンチマークを書く。

package zundoko

import "testing"

func BenchmarkRun1(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Run()
    }
}

func BenchmarkRun2(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Run2()
    }
}

BenchmarkRun1 が従来のもの， BenchmarkRun2 が先程の match() 関数を使ったバージョンである。結果は以下のとおり。

$ go test -bench Run -benchmem
testing: warning: no tests to run
PASS
BenchmarkRun1-4    50000     28141 ns/op    1800 B/op     9 allocs/op
BenchmarkRun2-4    30000     40102 ns/op    3912 B/op   115 allocs/op
ok      github.com/spiegel-im-spiegel/zundoko   4.261s

乱数の要素が絡むので毎回同じ値ではないが，傾向としてはこんな感じ。 BenchmarkRun2 のほうが allocation 回数が圧倒的に多いのが分かるだろう。これがスピードにもダイレクトに反映されている感じである。

今回は「「ズン」が4回以上連続で来た直後に「ドコ」が来たら OK」という単純なロジックだったが，もっと複雑なパターンが要求される場合は工夫が必要かもしれない²。

「ズン」と「ドコ」の出現回数を数える関数も作ってみた。

//CountZunDoko returns count of "ZUN" and "DOKO" choirs
func (c *Choirs) CountZunDoko() (int, int) {
    z := 0
    d := 0
    if c == nil {
        return z, d
    }
    for _, s := range c.c {
        switch s {
        case Zun:
            z++
        case Doko:
            d++
        }
    }
    return z, d
}

たとえば generate() 関数内で使っている擬似乱数パッケージを別のものに換えた時に統計処理で簡単な性能評価ができるかもしれない。今回はそこまではしなけど（擬似乱数の話はいずれやりたい）。

こうやって手遊びでコードを弄るのは楽しいものである。

ブックマーク

ズンドコキヨシまとめ - Qiita
ズンドコキヨシ with Go (n番煎じ) - Qiita
ズンドコキヨシGolang並列版 - Qiita : 「ズン」「ドコ」の生成部分を CPU の数だけ並列処理で行わせてひとつの channel に入力するというユニークな実装
「ズンドコキヨシ」と擬似乱数 - Qiita : Qiita で擬似乱数について簡単にまとめてみた。整理できたらこちらでも記事にするかも

参考図書

プログラミング言語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)

math/rand の乱数生成アルゴリズムの既定は線形合同法らしい。線形合同法は性能が良くなくゲームや暗号等では使えない。math/rand の乱数生成アルゴリズムは他のものに入れ替えることができる。たとえば seehuhn/mt19937 パッケージが使える。 ↩︎
たとえば container/list や container/ring といったパッケージを使う手がある。 ↩︎

素数探索アルゴリズムで遊ぶ

2015-09-17T12:23:42+00:00

（初出：はじめての Go 言語 (on Windows) その2 - Qiita）

Go 言語は公式のドキュメントがとても充実していて（ただしほぼ英語だけど），私のような初学者に易しい環境といえる。

Documentation - The Go Programming Language : 言語仕様に関するドキュメントはこちら（一部日本語化されている）
Packages - The Go Programming Language : 標準パッケージのドキュメントはこちら（一部日本語化されている）

とはいえ，コードが実際にどのように機能するかは書いてみないと分からない部分もある。なので，今回からは実際にコードを書きながら言語の癖のようなものを調べていくことにする。仕事に使うなら厳密な評価が必要だけど，今のところはそんな予定もないし，まずはテキトーで（笑）

早速，みんな大好き素数探索アルゴリズムで遊ぶ。

素数の定義

一応，素数（prime number）の定義を以下に示す。

1 と自分自身以外に正の約数を持たない 1 より大きい自然数

ここで自然数（natural number）は「ペアノの公理」に従う（0 が自然数に含まれるかどうかについては色々あるみたいだが，素数の定義には影響がないので，ここでは無視する）。

ちなみに結城浩さんの『数学ガール／ゲーデルの不完全性定理』にペアノの公理について分かりやすく解説した章がある。お勧め。

素数探索アルゴリズム（その1）

素数の定義を愚直にコードで表すなら以下のようになる。

package main

import (
    "fmt"
    "time"
)

func main() {
    max := 100
    primes := make([]int64, 0) // 素数のリスト

    start := time.Now() //Start
    for n := 2; n <= max; n++ {
        flag := true
        for m := 2; m < n; m++ {
            if (n % m) == 0 { // n が m で割り切れる → 素数ではない
                flag = false
                break
            }
        }
        if flag {
            primes = append(primes, int64(n)) // 素数を追加
        }
    }
    goal := time.Now() //Goal
    fmt.Printf("%v 以下の素数: %v\n", max, primes)
    fmt.Printf("%v 経過", goal.Sub(start)) //経過時間を表示
}

実行結果はこんな感じ。

C:>go run prime01.go
100 以下の素数: [2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97]
0 経過

この値を覚えておいてね。検算に使うから。

素数探索アルゴリズム（その2: エラトステネスの篩の変形）

もう少しだけ効率的に素数を探すアルゴリズムとして「エラトステネスの篩」と呼ばれる方法がある。コードで書くとこんな感じ。

package main

import (
    "fmt"
    "time"
)

func main() {
    max := 100
    primes := make([]int64, 0)        // 素数のリスト
    isNotPrime := make([]bool, max+1) // false で初期化される（全てを素数候補とする）
    isNotPrime[0] = true              // 0 は非素数
    isNotPrime[1] = true              // 1 は非素数

    start := time.Now() //Start
    n := 2
    for ; n*n <= max; n++ { // √max まで篩にかける
        if !isNotPrime[n] { // n は素数
            primes = append(primes, int64(n)) // 素数を追加
            for m := 2; n*m <= max; m++ {
                isNotPrime[n*m] = true // max 以下の n の倍数を全て非素数とする
            }
        }
    }
    for ; n <= max; n++ {
        if !isNotPrime[n] { // n は素数
            primes = append(primes, int64(n)) // 素数を追加
        }
    }
    goal := time.Now() //Goal
    fmt.Printf("%v 以下の素数: %v\n", max, primes)
    fmt.Printf("%v 経過", goal.Sub(start)) //経過時間を表示
}

C:>go run prime01b.go
100 以下の素数: [2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97]
0 経過

割り算がない。ブラボー！

ただし「エラトステネスの篩」は決まった範囲を探索するものなので少々使いづらい。しかも掛け算を使うので大きな数を探索するのには向いていない。そこで「エラトステネスの篩」で使われている以下の素数の特徴を最初のアルゴリズムに加えてみる。

2 以上の全ての自然数はひとつ以上の素数の積で構成される（この素数の集合を素因数（prime factor）という）。したがってある数が素数か否かの判定は，その数より小さい素数のみで調べればよい
更に，積の可換則（commutative property あるいは交換法則）により，自然数 $n$ が素数か否か判定する場合は $\sqrt{n}$ 以下の素数で調べればよい
（たとえば 35 の素因数は 5 と 7 だが， $5 \times 7 = 7 \times 5 = 35$ なので，直前の素数 31 まで回さずとも 3 および 5 ($\le \sqrt{35}$) まで調べれば判定できる）
素数の定義から 2 が素数であることは自明なので（1 と 2 の間に自然数は存在しない）， 2 より大きい 2 の倍数（すなわち偶数）については判定しなくてもよく，対象となる自然数は 3 以上の奇数のみでいいことになる。

では，この特徴を加えたコードを書いてみよう。

package main

import (
    "fmt"
    "math"
    "time"
)

func main() {
    primes := make([]int64, 1)     // 素数のリスト
    primes_f := make([]float64, 1) // 素数のリスト（浮動小数点へのキャスト）
    primes[0] = 2                  // 2 は素数
    primes_f[0] = 2.0              // 2 は素数（浮動小数点）
    var max int64 = 100

    start := time.Now() // Start
    var n int64 = 3
    for n = 3; n < max; n += 2 { // 3 から始まる奇数のみを探索
        flag := true
        f := float64(n)                    // 浮動小数点に cating
        rf := math.Sqrt(f)                 // n に対して √n をとる
        for i := 1; i < len(primes); i++ { // 2 より大きい既知の素数でチェックする
            if primes_f[i] > rf { // n に対して √n 以下の素数まで探索すればよい
                break
            } else if (n % primes[i]) == 0 { // n が既知の素数で割り切れる → 素数ではない
                flag = false
                break
            }
        }
        if flag {
            primes = append(primes, n)     // 素数を追加
            primes_f = append(primes_f, f) // 素数を追加（浮動小数点）
        }
    }
    goal := time.Now() // Goal
    fmt.Printf("%v 以下の素数: %v\n", max, primes)
    fmt.Printf("%v 経過", goal.Sub(start)) // 経過時間を表示
}

実行結果はこんな感じ。

C:>go run prime02.go
100 以下の素数: [2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97]
0 経過

slice と make() と append()

コード中

primes := make([]int64, 1)     // 素数のリスト
primes_f := make([]float64, 1) // 素数のリスト（浮動小数点へのキャスト）
primes[0] = 2                  // 2 は素数
primes_f[0] = 2.0              // 2 は素数（浮動小数点）

の変数 primes および primes_f は slice と呼ばれる可変長の配列型である。更に組み込み関数 make() は slice, map, channel のみ使用可能なメモリ割り当て関数である。ちなみに slice, map, channel 以外は new() を使う。 slice, map, channel のみ特別なのは，これらの型は初期値と内部状態を持つためである。

slice に要素を追加する場合は append() 関数を使えばいいのだが，これが結構クセがある。 append() 関数では slice の容量（capacity）がいっぱいになると新たにメモリを確保してオリジナルの内容をコピーする。つまりポインタが変わってしまうのだ。（メモリの割り当て方のパターンにも注目）

package main

import "fmt"

func main() {
    a := make([]int, 0)                                         // 空の配列を用意
    fmt.Printf("Slice(%02d) : %p : %v (%v)\n", 0, a, a, cap(a)) // 配列の表示（初期状態）
    for num := 1; num <= 17; num++ {
        a = append(a, num)                                            //配列要素の追加
        fmt.Printf("Slice(%02d) : %p : %v (%v)\n", num, a, a, cap(a)) //配列の表示
    }
}

C:>go run slice.go
Slice(00) : 0x5cebb8 : [] (0)
Slice(01) : 0xc082002340 : [1] (1)
Slice(02) : 0xc082002380 : [1 2] (2)
Slice(03) : 0xc082006740 : [1 2 3] (4)
Slice(04) : 0xc082006740 : [1 2 3 4] (4)
Slice(05) : 0xc0820083c0 : [1 2 3 4 5] (8)
Slice(06) : 0xc0820083c0 : [1 2 3 4 5 6] (8)
Slice(07) : 0xc0820083c0 : [1 2 3 4 5 6 7] (8)
Slice(08) : 0xc0820083c0 : [1 2 3 4 5 6 7 8] (8)
Slice(09) : 0xc082050000 : [1 2 3 4 5 6 7 8 9] (16)
Slice(10) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10] (16)
Slice(11) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11] (16)
Slice(12) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12] (16)
Slice(13) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13] (16)
Slice(14) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14] (16)
Slice(15) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15] (16)
Slice(16) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16] (16)
Slice(17) : 0xc082056000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17] (32)

容量が変化するごとにポインタ値も変化していることがお分かりだろうか。

ちなみに Go コンパイラは，返値を無視するコーディングに対してエラーを吐く。

a = append(a, num)

の部分を

append(a, num)

とすると

C:>go run prime02.go
# command-line-arguments
.\slice.go:9: append(a, num) evaluated but not used

とエラーになる。

また，容量はあらかじめ指定できる。

a := make([]int, 0)

の部分を

a := make([]int, 0, 32)

とすると

C:>go run slice.go
Slice(00) : 0xc082050000 : [] (32)
Slice(01) : 0xc082050000 : [1] (32)
Slice(02) : 0xc082050000 : [1 2] (32)
Slice(03) : 0xc082050000 : [1 2 3] (32)
Slice(04) : 0xc082050000 : [1 2 3 4] (32)
Slice(05) : 0xc082050000 : [1 2 3 4 5] (32)
Slice(06) : 0xc082050000 : [1 2 3 4 5 6] (32)
Slice(07) : 0xc082050000 : [1 2 3 4 5 6 7] (32)
Slice(08) : 0xc082050000 : [1 2 3 4 5 6 7 8] (32)
Slice(09) : 0xc082050000 : [1 2 3 4 5 6 7 8 9] (32)
Slice(10) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10] (32)
Slice(11) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11] (32)
Slice(12) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12] (32)
Slice(13) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13] (32)
Slice(14) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14] (32)
Slice(15) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15] (32)
Slice(16) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16] (32)
Slice(17) : 0xc082050000 : [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17] (32)

となる。メモリ割り当ては意外に高コストの操作なので， slice を扱う場合はこの辺がチューニング・ポイントになるだろう。

100万個目の素数

上のコードを少し修正して $x$ 個目の素数を調べることにしよう。

package main

import (
    "flag"
    "fmt"
    "math"
    "os"
    "strconv"
    "time"
)

func main() {
    //コマンドライン引数の解析
    algno := flag.Int("alg", 0, "0: Basic algorithm , 1: Sieve of Eratosthenes")
    flag.Parse()
    args := flag.Args()
    if *algno < 0 || *algno > 1 {
        fmt.Fprintln(os.Stderr, os.ErrInvalid)
        return
    }
    if len(args) != 1 {
        fmt.Fprintln(os.Stderr, os.ErrInvalid)
        return
    }
    max, err := strconv.ParseInt(args[0], 10, 64)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
    if max <= 0 {
        max = 1
    }

    //素数探索
    prime := int64(0)
    start := time.Now() // Start
    switch *algno {
    case 1:
        prime = LastPrimeE(max)
    default:
        prime = LastPrimeB(max)
    }
    goal := time.Now()                       // Goal
    fmt.Printf("%v 個目の素数: %v\n", max, prime) // max 個目の素数
    fmt.Printf("%v 経過\n", goal.Sub(start))   // 経過時間を表示
}

func LastPrimeB(max int64) int64 {
    count := int64(0)

    for n := int64(2); ; n++ {
        flag := true
        for m := int64(2); m < n; m++ {
            if (n % m) == 0 { // n が m で割り切れる → 素数ではない
                flag = false
                break
            }
        }
        if flag {
            count++
            if count >= max {
                return n
            }
        }
    }
}

func LastPrimeE(max int64) int64 {
    if max <= 1 {
        return 2
    }
    primes := make([]int64, 1, max)     // 素数のリスト
    primes_f := make([]float64, 1, max) // 素数のリスト（浮動小数点へのキャスト）
    primes[0] = 2                       // 2 は素数
    primes_f[0] = 2.0                   // 2 は素数（浮動小数点）

    count := int64(1)
    for n := int64(3); ; n += 2 { // 3 から始まる奇数のみを探索
        flag := true
        f := float64(n)                    // 浮動小数点に cating
        rf := math.Sqrt(f)                 // n に対して √n をとる
        for i := 1; i < len(primes); i++ { // 2 より大きい既知の素数でチェックする
            if primes_f[i] > rf { // n に対して √n 以下の素数まで探索すればよい
                break
            } else if (n % primes[i]) == 0 { // n が既知の素数で割り切れる → 素数ではない
                flag = false
                break
            }
        }
        if flag {
            count++
            if count >= max {
                return n
            }
            primes = append(primes, n)     // 素数を追加
            primes_f = append(primes_f, f) // 素数を追加（浮動小数点）
        }
    }
}

今後のためにコマンドライン解析の部分と実際の素数探索アルゴリズムを分けている。まず検算。 25個目の素数が 97 なら OK。

C:>go run prime03.go -alg=0 25
25 個目の素数: 97
0 経過

C:>go run prime03.go -alg=1 25
25 個目の素数: 97
0 経過

では実際に動かしてみよう。まずは「その1」のアルゴリズムから。

C:>go run prime03.go -alg=0 100
100 個目の素数: 541
0 経過

C:>go run prime03.go -alg=0 10000
10000 個目の素数: 104729
4.4072521s 経過

100万個目の素数は有意の時間で見つかりませんでした orz

次に「その2」のアルゴリズムで。

C:>go run prime03.go --alg=1 100
100 個目の素数: 541
0 経過

C:>go run prime03.go --alg=1 10000
10000 個目の素数: 104729
7.0004ms 経過

C:>go run prime03.go --alg=1 1000000

1000000 個目の素数: 15485863
4.9042805s 経過

C:>go run prime03.go --alg=1 10000000
10000000 個目の素数: 179424673
2m13.8686568s 経過

というわけで，100万個目の素数探索に5秒弱，1000万個目の素数探索に2分ちょっとかかってしまった。まぁ，でも，こんなもんか。

素数探索アルゴリズム（その3: エラトステネスの篩を並行処理で）

これまでのアルゴリズムは基本的に2重のループで値を順番に付き合わせているだけだったが，この部分を並行処理で行えば速いんじゃね？と思うよね。

Go 言語で並行処理を行うには goroutine（「ゴルーチン」と読むらしい）を使う。また goroutine の worker 間ではメモリ共有ができないため， channel を使い message-passing 方式¹で通信を行う。

で，実際にチュートリアルには並行処理を使った素数探索アルゴリズムが紹介されている²。いくつかサイトを巡ったが，このやり方がもっとも素直なようだ（後述するが速いわけではない）。そこで，このコードを流用させてもらうことにした。

func LastPrimeE2(max int64) int64 {
    if max <= 1 {
        return 2 // 最初の素数は2
    }

    count := int64(1)
    primes := sieve()
    for {
        prime := <-primes
        count++
        if count >= max {
            return prime
        }
    }
}

// 素数候補の数を生成する
func generate() chan int64 {
    ch := make(chan int64)
    go func() {
        for n := int64(3); ; n += 2 { // 3 以降の奇数を送信（2 以外の偶数は素数ではない）
            ch <- n
        }
    }()
    return ch
}

// 素数 'prime' に対するフィルタ
// 'prime' で割り切れない値のみ通過可能
func filter(in chan int64, prime int64) chan int64 {
    out := make(chan int64)
    go func() {
        for {
            n := <-in
            if (n % prime) != 0 {
                out <- n
            }
        }
    }()
    return out
}

// エラトステネスの篩
func sieve() chan int64 {
    out := make(chan int64)
    go func() {
        ch := generate()
        for {
            prime := <-ch
            out <- prime
            ch = filter(ch, prime)
        }
    }()
    return out
}

そうそう。 Go 言語では関数は全て関数閉包（closure）として機能する。

main 関数も少しいじって -alg=2 でこのアルゴリズムを起動するようにする。まずは検算ね。

C:>go run prime04.go -alg=2 25
25 個目の素数: 97
0 経過

じゃあ，早速うごかしてみよっか。

C:>go run prime04.go -alg=2 100
100 個目の素数: 541
2.0002ms 経過

C:>go run prime04.go -alg=2 10000
10000 個目の素数: 104729
4.2002402s 経過

100万個目の素数は有意の時間で見つかりませんでした orz

まぁアルゴリズム的に「篩」っぽくはあるんだけどね。

ある値が素数であると判定されるためには，その値より小さい全ての素数フィルタを通過しなければならない（つまり「その2」で紹介した特徴の2番目を全く生かせていない）。これが致命的。しかもこのフィルタ処理 filter() は素数フィルタの生成も兼ねていて，前の素数フィルタの出力を次の素数フィルタの入力として連結しているのでスキップできない。

かなりインチキではあるけど，捜索範囲を「100万個目」までと限定し，「100万個目」の素数が 15,485,863 であると分かっているならもう少し速くできるかもしれない。つまり以下のように改良する。

func LastPrimeE2(max int64) int64 {
    if max <= 1 {
        return 2 // 最初の素数は2
    }

    count := int64(1)
    primes := sieve()
    for prime := range primes {
        count++
        if count >= max {
            return prime
        }
    }
    return count
}

// 素数候補の数を生成する
// ただし上限を 15485863 とする
func generate() chan int64 {
    ch := make(chan int64)
    go func() {
        for n := int64(3); n <= 15485863; n += 2 { // 3 以降の奇数を送信（2 以外の偶数は素数ではない）
            ch <- n
        }
        close(ch)
    }()
    return ch
}

// 素数 'prime' に対するフィルタ
func filter(in chan int64, prime int64) chan int64 {
    out := make(chan int64)
    go func() {
        for n := range in {
            if (n % prime) != 0 {
                out <- n
            }
        }
        close(out)
    }()
    return out
}

// エラトステネスの篩
func sieve() chan int64 {
    out := make(chan int64)
    go func() {
        ch := generate()
        fflag := true
        for {
            prime, ok := <-ch
            if !ok {
                break
            }
            out <- prime
            if fflag && prime*prime <= 15485863 {
                ch = filter(ch, prime)
            } else { // 素数が最大値の平方根（√15485863）より大きい場合はフィルタを作らず無条件に通す
                fflag = false
            }
        }
        close(out)
    }()
    return out
}

これで実行してみる。

C:>go run prime05.go -alg=2 100
100 個目の素数: 541
2.0001ms 経過

C:>go run prime05.go -alg=2 10000
10000 個目の素数: 104729
378.0216ms 経過

C:>go run prime05.go -alg=2 1000000
1000000 個目の素数: 15485863
39.4492564s 経過

おお。ようやく有意の時間で探索できた。それでも「その2」の10倍以上かかるけど。

channel への送信データが有限個の場合は最後に close(ch) でクローズする。一方 channel からの受信側は for range 構文を使うことで安全に扱うことができる。ただし上述の sieve() 関数では変数 ch が新しい素数フィルタの出力に上書きされていくので for range 構文は使えない。その代わり以下の記述で channel を安全に扱うことができる。

prime, ok := <-ch
if !ok {
    break // channel が閉じられた
}

今回はここまで。

ブックマーク

Go の並行処理 - Block Rockin’ Codes
(翻訳)Goでのパイプラインとキャンセル - Qiita
Go: 計算なしのFizzBuzz - Qiita : channel の説明するのにいいかも
Goのchannelの送受信用の型について - Qiita
Go言語のChannelは送信時にもブロックする - Qiita : 意外と見落とす channel 送信時のブロック
Go - select loop の小ネタ - Qiita
Goのforとgoroutineでやりがちなミスとたった一つの冴えたgo vetと - Qiita
golang - x/net/context の実装パターン - Qiita : golang.org/x/net/context を使って並行処理を細かく制御
Go言語でCPU数に応じて並列処理数を制限する | SOTA
やはり俺のgolangがCPUを一つしか使わないのはまちがっている。 - Qiita
Golangで「エラトステネスの篩」で「2.1秒で百万個」の素数を計算できる「無限シーケンス」を作ってみた - Qiita

Go 言語に関するブックマーク集はこちら。

参考図書

数学ガール／ゲーデルの不完全性定理: 結城浩 (著); SBクリエイティブ 2009-10-23 (Release 2014-03-12); Kindle版; B00I8AT1D6 (ASIN); 評価

[Comment] 結城浩さんの本はよく整備された遊歩道を散歩するような気楽さと安心感がある。だから「フェルマーの最終定理」とか「ゲーデルの不完全性定理」とかいった難解そうなテーマでも，迷うことなく，しかも一歩ずつ歩みを進めてゴールまで辿り着けるのかもしれない。

reviewed by Spiegel on 2014-10-21 (powered by PA-APIv5)

message-passing 方式は Erlang などで一躍有名になったやつ。ただし Erlang ではプロセス間通信の手段として message-passing を使う。これは Actor と呼ばれている。 goroutine は「並行処理」であり「並列処理」ではない。また，いわゆる thread とも異なる。Go 言語で並列処理を行うなら「Go言語でCPU数に応じて並列処理数を制限する」あたりが参考になる。 ↩︎
ただし現在の公式ドキュメントには存在しない。 ↩︎

List of Goroutine [text.Baldanders.info]

time.Ticker で遊ぶ【Go 1.16 バージョン】

一定周期ごとの処理を行う

NotifyContext 関数で SIGNAL を捕まえる

キャンセル・イベントの伝搬

ブックマーク

参考図書

Go の疑似乱数生成器は並行的に安全ではないらしい（追記あり）

goroutine ごとにインスタンスを生成する

Generator Pattern を使う

おまけの追記

【2019-09-20 追記】 実は標準で並行的に安全な疑似乱数生成器が用意されていた

ブックマーク

参考図書

『Go 言語による並行処理』は Go 言語プログラマ必読書だろう

ブックマーク

参考図書

time.Ticker で遊ぶ

一定周期ごとの処理を行う

SIGNAL を捕まえる

キャンセル・イベントの伝搬

【追記】 Windows では SIGNAL を送信できない

ブックマーク

参考図書

Go 言語における Singleton Pattern

ブックマーク

参考図書

「ズンドコチェック」なるものが流行っているらしい

ブックマーク

参考図書

素数探索アルゴリズムで遊ぶ

素数の定義

素数探索アルゴリズム（その1）

素数探索アルゴリズム（その2: エラトステネスの篩の変形）

slice と make() と append()

100万個目の素数

素数探索アルゴリズム（その3: エラトステネスの篩を並行処理で）

ブックマーク

参考図書

【2019-09-20 追記】実は標準で並行的に安全な疑似乱数生成器が用意されていた