サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
JRuby is aRuby implementation that runs on theJava VirtualMachine (JVM).It allowsRuby code to leverageJava libraries and frameworks and enables deployment on JVM platforms likeAndroid. TheJRuby team maintains and improvesJRuby, but much of the underlying infrastructure like memory management, threading, and JIT compilation is provided by the JVM, allowing the team to focus onRuby-specifi
Twitterから転載 ふとスレッドっていつ発明されたんだろうと調べてみたけどよくわからない。Linuxがカーネルスレッドをサポートしたのが2.6からで2003年とか意外と新しい？？もちろんユーザレベルのスレッドはもっと古いんだろうけど、いつからだろう。 hideaki_t: NeXTSTEP(Mach 2.0?)にはcthreadがありました。 atsuoishimoto: 私がスレッドって用語初めて聞いたのは、たしか'90年代初頭のOS/2だったかなぁ？ これが2004年の話か＞NetBSD 2.x+, and DragonFly BSD implement LWPs as kernel threads (1:1 model) shidocchi: 私は院の研究室でMachのソースリーディングをやってた頃知った。 これが2001年 ＞ October 2, 2001Mac OS X
もはや誰得レベルになりつつありますが、今回もメモリバリアについての話です。以前の話の続きになるので、まだの方は初回と前回のエントリを先にどうぞ。 さて、まず最初に、C++0xのatomicクラスを使った「正しく同期化されているコード」の例を挙げてみます。 struct Hoge { int foo; }; // 初期値 std::atomic p(nullptr); // Thread 1 Hoge* r1 = new Hoge(); r1->foo = 42; p.store(r1, std::memory_order_release); // Thread 2 Hoge* r2; do { r2 = p.load(std::memory_order_acquire); } while (r2 == nullptr); std::cout << r2->foo; // 42が出力されるこ
前のエントリで次期C++標準(通称C++0x)にatomic型とメモリバリアが導入されるという話をしました。今回はそのC++での実装について、もう少し深く追いかけてみます。 スライド資料では「atomic操作 ＋ acquire/releaseバリア」が基本であると書きましたが、実際に次期C++に導入される予定のatomicAPIは、もう少し複雑な仕様になっています。一番の違いは、メモリバリアの種類が増えていることです。 次期C++標準の現在のドラフトでは、メモリバリアの種類を表すenum型の定義は以下のようになっています。 namespace std { typedef enum memory_order { memory_order_relaxed, memory_order_consume, memory_order_acquire, memory_order_release, m
今回は "Double-Checked Locking" (以下DCL)というマルチスレッドプログラム向けのイディオムを例にして、C++0xの(低レイヤ向け)マルチスレッド機能の利用方法を紹介してみます。 DCLとは、「ロック→条件判定」というロジックを「条件判定→ロック→(再度)条件判定」と書き換えるイディオムで、主に遅延初期化などの処理においてロックのオーバーヘッドを減らすために用いられます。DCLはシンプルかつ効果の高いイディオムだったので、一時期もてはやされました。ところが、DCLはコンパイラやCPUによるリオーダーの影響により正しく動作しない場合があることがわかったため(参考1、参考2)、今ではアンチパターンと呼ばれることすらある始末です。 しかし、DCLの問題点は、メモリモデルに関する知識があまり知られていなかったことと、プログラミング言語の仕様でメモリモデルが正しく定義されて
For a while now, theRuby community has become enamored in the latest new hotness, eventedprogramming and Node.js.It'sgone so far that I've heard a number of prominentRubyists saying thatJavaScript and Node.js are the only sane way to handle a number of concurrent users. I should start by saying that I personally love writing eventedJavaScript in the browser, and have been giving talks (for
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
