Lessons Learned in Concurrency with Ruby - Part I
The Engine Yard PaaS products are highly complex, and span thousands of servers to serve our customers. Ensuring that our applications run quickly and reliably requires a good understanding of concurrency and parallelization. This blog post is a recap of my journey down the rabbit hole of concurrency in an attempt to solve this problem in my own development efforts. Part II will be the continuatio
non-blockingの意味するところ - くまメモ
海外の文献を読み漁っていると気づくのですが 2003年を境にこの文脈で使われる言葉の定義が変わります。 ↑2003年ごろまでの構図 ↑現在の構図。*1 non-blocking = obstruction-free という理解でもおおよそ間違いではないとは思いますが 論文を読むに当たって non-blocking = ロックを使わないアルゴリズム全般 obstruction-free = 非lock-freeだけどロックだけはしない というニュアンスの違いを感じます。 以後、現在の構図の方を前提に話します。ご注意ください。 まずは3つの分類の違いから wait-free 操作が「他のスレッドの動向に関わらず有限ステップで完了できる」場合、そのアルゴリズムはwait-freeと呼ばれます。starvation-freeと呼んだりもします。 実際には初めからここに分類されるアルゴリズムは多くあ
Lock-free Stack - くまメモ
ではLock-free Stackについて図とプログラムを交えながら説明します。C++ではなくCを使います。 これは複数スレッドからロックによる排他無しで共有できるスタックで、外部には node* top; void push(const T*, node** top); bool pop(T*, node** top); を提供します。*1 このスタックはbottomへと繋がる線形リストをベースとして動作するため、配列ベースのスタックにパフォーマンスで劣ることもあります。*2 その線形リストを構成するノードのデータ構造から見てみましょう。 struct node{ T data; node* next; }; ごく典型的な線形リストのノードと同じです。 道具の紹介 lock-freeデータ構造を構成する場合に頻出のCompare And Swap。 C言語の擬似コードで書くと以下のような
モダン並列・並行プログラミング ～ Concurrent Revisions による実装と現実 ～ - Preferred Networks Research & Development
本日社内向けのTechTalkにて、並列・並行プログラミングに関する話を行いました。 昨今、プログラムの並列化はなくてはならないものとなっています。しかし、そのプログラミング環境は依然としてロックを用いたものが主流です。今回の発表の主張を端的に申し上げますと、 “Locks must go！” ということになります。並列プログラミングに銀の弾丸はありません。しかし、ロックは別の何らかの安全性を確保したプログラミングモデルで置き換えられなければいけません。そうでなければ、再現しにくいバグに苦しめられ、終電を逃す日々と決別することはできないでしょう。また、ロックによるプログラミングの抱える本質的問題にも言及しています。 この界隈の最新の動向として、去年OOPSLA’10にて発表されたConcurrent Revisionsについての解説も行なっております。また、弊社研究開発において、先日Con
並列アルゴリズムについて
お急ぎの方は, 短縮versionをどうぞ. 【並列アルゴリズムとは】 地球環境のシミュレーション, 天気予報で用いられる数値予報, 量子力学に基づく分子設計, 原子物理, 宇宙物理のシミュレーション, 流体の計算, 経済, 社会システムのシミュレーション, コンピュータグラフィックス, 広域通信網, 電力網等の最適設計, 画像処理, 大規模データベース, 大規模知識ベースの検索等, 従来の逐次型計算機では扱うのが困難な大規模かつ複雑な問題を解く必要性から, 並列計算機への関心が高まってきており, 既に, コネクションマシン[HIL 90]等の商用機も市場に出された. しかしながら, 逐次型計算機用に書かれたプログラムをそのまま 並列計算機にかけて効率良く処理させることができるような並列化コンパイラは 極く限られた用途のものを除いては当面開発されそうもない. 従って,
The "Double-Checked Locking is Broken" Declaration
The "Double-Checked Locking is Broken" Declaration Signed by: David Bacon (IBM Research) Joshua Bloch (Javasoft), Jeff Bogda, Cliff Click (Hotspot JVM project), Paul Haahr, Doug Lea, Tom May, Jan-Willem Maessen, Jeremy Manson, John D. Mitchell (jGuru) Kelvin Nilsen, Bill Pugh, Emin Gun Sirer Double-Checked Locking is widely cited and used as an efficient method for implementing lazy initialization
組み込み市場における、並列化言語の普及の可能性は？ | スラド デベロッパー
ストーリー by GetSet 2007年10月08日 17時30分 組込向けトレンドの明日はどっちだ？ 部門より EEtimes Japanの記事より。組み込み機器向けプロセッサもマルチコア・アーキテクチャへと徐々に移行している昨今だが、記事によるとマルチコアの性能を引き出す並列プログラミング言語はほとんど 利用されておらず、組み込み機器向けソフトウエアの開発者のうち85％はC言語またはC++言語を使っており、新しい 並列プログラミング言語が普及する可能性はほとんどないだろう、とされている。 マルチコアの性能を引き出すために並列プログラミング言語を利用する、というのは分からないでもないのですが、 組み込み向けでそんなに意識する必要があるのかな、という疑問も。そもそも「C/C++以外」を選択するメリットというのは、 どの程度あるのだろうか？
2000万個のプロセスを動かすための並列モデル - 最速配信研究会(@yamaz)
# タイトルは煽りです. 今週末ドリコムさんでCometとその周辺技術（イベント処理、Erlangなどなど）に関する勉強会が行われるので,ここ最近つらつら考えたり調べたりしてたことを外に出します.yamazはErlangの文法とかにはあまり興味がなく,2000万のプロセスが並列実行できるというそのモデルに興味があるので,とりあえずそこについて. なおいつもにも増して適当なこと書いてるので,適宜マユツバでお願いします.ツッコミ大歓迎. Erlangは1マシンで2000万のプロセスを並列実行させることができるらしい. http://www.atmarkit.co.jp/news/200704/27/erlang.html 私は並列言語はVHDLしか使ったことがなく,しかもVHDLはちゃんと 並列実行を行う要素が回路の形で実在するので,Erlangみたいに 1マシンで並列性を実現することに対して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Efficient data transfer through zero copy
TotT: Sleeping != Synchronization
Efficient data transfer through zero copy
IBM Developer
The Death of "synchronized"?
TheServerSide | Your Java Community discussing server side development
Programming for Parrallelism: The Parallel Hierarchies Pattern
10 Ways to Reduce Lock Contention in Threaded Programs - Thinking Parallel
Intel open sources multicore programming tool
IBM Developer
Ten Questions with Joe Duffy about Parallel Programming and .NET Threads - Thinking Parallel
The Problem with Threads | …on Coding | Algorithm.com.au