Golang Cafe #51を開催しました。

Golang Cafe #51を開催しました。今回は結城浩さんの書籍「増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編」のThread-Per-MessageパターンをGoで書くとどうなるか？というお題に挑戦しました。

Thread-Per-Messageパターンがどういうものかというと、「これやっといてね」とメインスレッドが要求を出します。この要求ごとにスレッドが生成され、ワーカースレッドがそれぞれを処理して終了するというものです。

今回はワーカスレッドの代わりに、Goroutineを生成して、終了をChannelで待つという、以前と余り変わらないコードになりました。（Javaの場合は、ワーカースレッドが動いているとプロセスが終了しないが、Goの場合はmain()が終了するとプロセスが終了してしまうので、終了待ちをする必要がある）
作成したのは以下のコードです。結局、Javaを力づくで翻訳した以前のコードとあまりかわらない結果になってしまいました。

問題点は、「Goroutineの終了」をどうやって待つか。と言うところが、今回のポイントになりました。実際のところは、Channelを戻り値で受け取り、for文で全てを受信待ちする（今回のパターン）か、selectを使った待ち方をすることになると思いますが、今回のように全てが終わったらその時点で終了。なら、for文で良いのかな？と考えてたりします。

ちゃんとした（正規のサービスで使う）プログラムの場合は、タイムアウトとか、close()させることもあると思いますからselect文を使うパターンの方が多いのかもしれません。

その他に、私も初めて気がついたのですが、syncパッケージにtype Poolというのが存在していました。そこで少し試しにコードを書いてみました。
sync.Poolは、複数のGoroutineからアクセスされても安全に取得できるように作られていて、GCの影響が少なくなるようになっているようです。
（確かにソースコードを見ると、unsafeが使われているようなので、GCの影響が少なくなるのかも？）

実際にGet()してみたところ、なんとなくですが、順番の保証はされていないような感じがします。（runtime.GOMAXPROCS()を呼びださなくても、順番が正しく動いていない気もする…）

ですが、順番が気にならないのであれば、sync.Poolを使うほうが排他制御を考えなくても良い分使いやすいかもしれません。（グローバル変数を同期して…。的なコードを書かなくても良くなる。ただし、それが悪いとは言っていませんのでご注意を。）

次回、（今日）はisuconの過去問題に挑戦してみます。私はAmazonのクラウド環境を使ったことがないので、そこからかな…。