A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
T/O マルチスレッド・プログラミングの文脈では、「データ競合(data race)」と「競合状態(race condition)」は直交した異なる概念を表す1。両者ともに回避すべき事象だが、問題を取り扱うレイヤは明確に区別されるべき。 データ競合(data race)は、マルチスレッド・プログラム実装上の問題である。 競合状態(race condition)は、並行処理システム設計上の問題である。 ここではJava, C#, C++あたりのマルチスレッド対応手続き型ベースのプログラミング言語を取り上げるが、言語パラダイムによらずマルチスレッド処理(共有メモリ型の並行処理機構)ならば広範に適用可能である。また言語仕様として両者を明確に区別するRust言語も取り上げる。 「データ競合(data race)」が何であるかは、それぞれのプログラミング言語仕様にて定義される。競合状態(race c
今回は、Go言語の並行・並列処理のかなめともいえるgoroutine(ゴルーチン)周りを掘り下げていきます。 goroutineは、前回の記事で軽く触れたように、軽量スレッドと呼ばれるものです。 そこで、まずはこの軽量スレッドと通常のOSのスレッドがどう違うのかを説明します。 そのうえで、goroutineの低レベルな機能を扱うためのruntimeパッケージ、 goroutineのデータ競合を発見するRace Detecter、 さらに高度な非同期処理を書くときに必要になるsyncパッケージおよびsync/atomicパッケージの使い方を紹介します。 スレッドとgoroutineの違い スレッドとは、プログラムを実行するための「もの」であり、OSによって手配されます。 プログラムから見たスレッドは、「メモリにロードされたプログラムの現在の実行状態を持つ仮想CPU」です。この仮想CPUのそれ
Goというプログラミング言語の強みの1つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす
5年前に買った『Java並行処理プログラミング ―その「基盤」と「最新API」を究める―』をようやく読んだ。買った頃には Perl やシンプルな JavaScript ばかり書いていたので並行プログラミングなんてほとんど気にすることがなく、実感がなくて読むのも途中で止まってしまっていた本で、家を掃除しているときに見つけたもの。その後も趣味で Android アプリを書くなど Java に触れる機会はあったけれど、せいぜいが AsyncTask を使うくらいで、マルチスレッドを強く意識してコードを書くこともなかった。 Java並行処理プログラミング ―その「基盤」と「最新API」を究める― 作者: Brian Goetz,Joshua Bloch,Doug Lea出版社/メーカー: ソフトバンククリエイティブ発売日: 2006/11/22メディア: 単行本購入: 30人 クリック: 442回
以前、このような記事を書きました。 Concurrency Utilitiesを使った並列処理・マルチスレッドのおさらい (2013-12-26) 前回の内容は、Concurrency UtilitiesだけでなくJavaのマルチスレッドの話も一部含んでいましたが、今回は、Concurrency Utilitiesだけにフォーカスして、全体が分かるように整理してまとめ直しました。 目次 概要 準備 タスク・フレームワーク (Executor) 同期キュー シンクロナイザー 並行処理コレクション 時間単位 アトミック値型とアトミック操作 ロック・フレームワーク 概要 今回は、Concurrency UtilitiesのAPIをいくつかのグループに分類し、それぞれのグループの主要な機能を「広く浅く」紹介する、という形式でまとめています。 パッケージ単位で分け、それからjava.util.con
Go Concurrency Patterns Rob Pike Google Video This talk was presented at Google I/O in June 2012. Watch the talk on YouTube 2 Introduction 3 Concurrency features in Go People seemed fascinated by the concurrency features of Go when the language was first announced. Questions: Why is concurrency supported? What is concurrency, anyway? Where does the idea come from? What is it good for? How do I use
intro ちょっと時間が経ってしまいましたが、 Go研 vol.03 では、 Google I/O 2013 で行われてた Go のセッションの 1 つである下記をテーマに研究しました。 Advanced Go Concurrency Patterns 資料は以下です。 https://github.com/goken/goken/blob/master/goken03/goken03.md また、ここから順に実装しながら解説をしますが、その完成品はこちらにあります。 (commit 履歴も、本記事にある程度沿っています。) https://gist.github.com/Jxck/5831269 スライドにそってやったのですが、セッションの内容は結構重ためだったので、 2 時間の Go 研だとちょっと消化不良ぎみだったのが反省点です。 そこで、このセッションの要である、並行処理に関する
一ヶ月ほどまえに Java 8 がリリースされました。ラムダも入ったことだし、お試しがてらゴールデンウィーク中に asterisque* の Scala コードの一部を Java で書き換える作業などを行っております。 ただまぁ asterisque* は非同期 RPC フレームワークですので、ラムダだけでなく Scala の Promise, Future もあちこちで使っています。うーんこいつらの互換性どうしようかなーと悩んでいたところ Java 8 に CompletableFuture というクラスが追加されいるのに気づきました。ざっと API リファレンスを読む限り以下のような特徴があります。 Scala の Future と同様に非同期処理間で成功 (計算結果) または失敗 (例外) を渡すことが出来る。 複数の処理スレッドで共有することも想定していて、早い者勝ちで結果を出すよ
この他にも "サービスを受けるのを待つ人が,キューの中に立っている平均時間はどれくらいか?" といったような疑問に,Littleの法則で答をだすといった内容のゲームは,他にもたくさんあります。 図1. Littleの法則 同じようにLittleの法則は,スレッドプールサイズの決定にも使うことができます。私たちがしなければならないのは,リクエストの到着率と,サービスに必要な平均時間を測定することです。そうすれば,これらの値をLittleの法則に挿入して,システムの平均要求数が計算されます。その数値がスレッドプールのサイズよりも小さければ,その結果に従ってプールのサイズを小さくすることが可能なのです。逆に計算結果がスレッドプールのサイズよりも大きい時には,問題はもう少し複雑になります。 実行中のリクエストより待ち状態のリクエストの数が多い場合,まず最初に判断しなければならないのは,もっと大きな
ThreadとHashMapに潜む無限回廊は実に面白い?:現場から学ぶWebアプリ開発のトラブルハック(10)(1/3 ページ) 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部) マルチスレッドのトラブルハックはさっぱり分からない… 対処が難しいトラブルといえば、GC(ガベージ・コレクション)とマルチスレッド処理に起因することが多い。 前々回(「肥え続けるTomcatと胃を痛めるトラブルハッカー 」)と前回(「JavaのGC頻度に惑わされた年末年始の苦いメモリ」)の2回にわたってGC、特にメモリ周りのトラブルを取り上げた。そこで今回は、マルチスレッド処理のトラブルの1つ、「レースコンディション(競合状態)
Painless multithreaded programming for RubyCelluloid is a concurrent object oriented programming framework for Ruby which lets you build multithreaded programs out of concurrent objects just as easily as you build sequential programs out of regular objects. Learn more Evented I/O for Celluloid actors. Build fast evented programs like you would with EventMachine or Node.js using regular synchronous
You don't have to choose between threaded and evented IO! Celluloid::IO provides an event-driven IO system for building fast, scalable network applications that integrates directly with the Celluloid actor library, making it easy to combine both threaded and evented concepts. Celluloid::IO is ideal for servers which handle large numbers of mostly-idle connections, such as Websocket servers or chat
multiprocessing Basics¶ The simplest way to spawn a second process is to instantiate a Process object with a target function and call start() to let it begin working. import multiprocessing def worker(): """worker function""" print('Worker') if __name__ == '__main__': jobs = [] for i in range(5): p = multiprocessing.Process(target=worker) jobs.append(p) p.start() The output includes the word “Work
本日社内向けのTechTalkにて、並列・並行プログラミングに関する話を行いました。 昨今、プログラムの並列化はなくてはならないものとなっています。しかし、そのプログラミング環境は依然としてロックを用いたものが主流です。今回の発表の主張を端的に申し上げますと、 “Locks must go!” ということになります。並列プログラミングに銀の弾丸はありません。しかし、ロックは別の何らかの安全性を確保したプログラミングモデルで置き換えられなければいけません。そうでなければ、再現しにくいバグに苦しめられ、終電を逃す日々と決別することはできないでしょう。また、ロックによるプログラミングの抱える本質的問題にも言及しています。 この界隈の最新の動向として、去年OOPSLA’10にて発表されたConcurrent Revisionsについての解説も行なっております。また、弊社研究開発において、先日Con
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く