goroutineがスイッチされるタイミング - Qiita
goroutineがスイッチされるタイミングについて調べていました。 結論 Go言語で、goroutineは 必ずしも スイッチされるわけではない。 スタックに触れないような、「for(){}」みたいなビジーループをGOMAXPROCSの指定数以上に含ませるとスイッチされなくなる。 goroutineがスイッチされる(主な)条件はこれらと思われる。 goroutineの関数が最適化でinline化されていない スタックを操作するような処理を行った (その他の契機もあるようなので「経緯」で書く) 経緯 処理のないビジーループが有ると、goroutineがスイッチされず処理が止まることに気づきました。 ＃ 処理の中身を全部コメントアウトしてデバッグしていたら気づいた
atomicパッケージが必要な理由と使い方 - Plan 9とGo言語のブログ
この記事はQiitaで公開されていました 以下のコードは通常分かりづらいバグを持っています。 package main import ( "fmt" "runtime" "sync" ) type Counter int32 func (c *Counter) Inc() { *c++ } func main() { var c Counter var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { c.Inc() wg.Done() }() } wg.Wait() fmt.Println("Count =", c, "GOMAXPROCS =", runtime.GOMAXPROCS(0)) } このコードは、GOMAXPROCS の値が2以上の場合、最後にプリントされるカウンタが1000にならない場
Go言語のio.Pipeでファイルを効率よくアップロードする方法
パイプ（土管）をGo言語でも楽しめるはじめに前回はGo言語のmime/multipartパッケージによるファイルのアップロードを見ましたが、パフォーマンスの特徴にはあまり触れませんでした。 大規模なETLジョブや、制限の厳しいサーバーレスの環境などでは、ファイルを扱うプログラムのリソースを慎重に考える必要があります。本記事ではメモリ使用量を大幅に減らすio.Pipeの使い方を見ていきます。 全てのコードはサンプルレポジトリにあります。 同期処理にある問題前回のコードをもう一度見てパフォーマンスを考えてみましょう。 // ファイルを開く file, _ := os.Open(filename) // リクエストボディのデータを受け取るio.Writerを生成する。 body := &bytes.Buffer{} // データのmultipartエンコーディングを管理するmultipart.W
Go言語でTCPやソケット通信を多重化，高速化するsmux(ソケットマルチプレクサ)をつくった · THINKING MEGANE
サーバ間で分散処理を行う際の相互通信におけるボトルネックを解消するため，smux(Socket multiplexer)を開発している． サーバ間の相互通信におけるボトルネックとその解決策 一対のサーバ間で多数のリクエストとレスポンスが送受信され，信頼性の高い通信としてTCPを利用する場合，コネクション確立のオーバーヘッドを排除するために接続の再利用が行われる．しかしながら，クライアントは送信に対する受信を待つ必要があるため，レスポンスまでに幾許かの処理時間を要する状況では送信のキューがたまってしまう．そこで複数の接続を利用することでこれを解消する方法が取られるが，追加の接続はリソース使用に関するオーバーヘッドを発生させてしまう．なにより各接続におけるレスポンス待ち時間は依然として解決しておらず，接続の利用面から見て非効率である．そこで，単一の接続において，仮想的に並行送受信を行う方法が提
Goroutineハンターが過労死する前に - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Goroutineハンター、それは逃げ出したgoroutine達を捕まえるため、日夜戦い続けるエンジニア達のことである。Goroutineハンターは本番環境でOOM Killerが発動するたびに呼び出され、逃げ出したすべてのgoroutineを捕まえるまで家にかえることが出来ない。しかし、あなたが書いた何気ないコードによって、今日もまた新しいgorutine達が野に放たれるのであった。 Goroutineリークとの戦い Goを使用してある程度規模のプログラムを書くと、必ず問題になるのがgoroutineのリークである。goで生まれたgo
Go言語の並行性を映像化する | POSTD
Goというプログラミング言語の強みの１つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす
Goでスレッド（goroutine）セーフなプログラムを書くために必ず注意しなければいけない点 - Qiita
Goは言語機能として並列実行をサポートしているけど、Goで書いたからといって自動的にデータ構造がスレッドセーフになるわけではないので、スレッド安全性を気にしなければならないはこれまでの言語と変わらない。どういうケースが良くてどういうケースがダメなのかを理解していないと安全なプログラムは書けない。それについて説明をしよう。 まず第一にEffective Goのこの一文は覚えておこう。 Do not communicate by sharing memory; instead, share memory by communicating. メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。 変数の値を変更したあとにチャネルなどを使わずに、おもむろに別のgoroutineからその変数の値を読み書きしてはいけない。そういうやり方だと読み書き操作の前後関係がき
pt&Goroutines
pt(the_platinum_searcher) を高速化するために Goroutines まわりで試したことを発表しました。 http://connpass.com/event/6370/
Goroutine Synchronization : D-7 <altijd in beweging>
（以下はgo 1.2.x時点での話です。将来的に仕様がかわるかどうかはわかりません） これを読んでいて、こういうの気にしてない人多いんだろうなーと思って、書いてみます。元のポストはdeferの挙動について語っているように見受けられるけれども、これは要は複数スレッドで実行されるコードについて、プログラム終了時に同期とか取りたくない、という話だと思ったので、このポストのdeferを正しく動かすには…というところからどういう形でgoroutine同士で同期を取る方法があるのか、一例を書き出していきます。 TL;DR; goでいくらgoroutineが気軽にかけるからと言って、複数スレッドで処理が行われているので同期はキチンとやらないとダメですよ。 deferの基本 goではLLのノリでコードを書けるのが売りの一つですが、メモリ管理はしてくれるものの、様々なリソース解放も全て自動というわけではあり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go Concurrency Patterns: Pipelines and cancellation - The Go Programming Language