そうめんのMonitorで先読み的なものをつくる | _level0 - KAYAC Front Engineer Blog
CubaClockのように大量に動画とか音楽を読み込むもの作るときにはそうめん(ThreadLiblary)のMonitorという機能を使うと便利です。 Monitorとは、機能的にいうと、あるものが使えないときは待つ、使えるときはデータ(リソース)を提供するものです。 具体的には、たとえば連続的に画像や音を表示しながら読み込みつづけるようなときに、データが十分にたまるまで待つ、たまったら普通に表示(or再生)、足りなくなったらまた待つ、といった処理を手軽に実現できます。 そうめんのサンプルにロードし続けるThreadと、データを見張るクラスのMonitorを介して、そのデータを使うThreadと間接的に連動するような実装をしたものがあります。 実は、ここの連動感が僕にとってすこしイメージしにくかったんですが、次のように整理すると理解できました。 まず、Queueというクラスを実装してこれ
Multi-Threaded Debuggerが地味にスゴくて泣ける - marsのメモ
この前その紹介記事見つけたんで，それを真似しながら実際動かしてみた。きしださんの例がちょうどよかったので，これを題材にしてみたよ。 Runner#run()の適当なところにブレイクポイント仕込んでデバッガを起動する。するとスレッドごとに同じ場所で止まるんで，こんな具合に教えてくれる（この時点ですでにスゴイ）。 適当なスレッド選んでステップ実行とかするわけなんだが，スレッドの一覧が表示されているんで，どんだけスレッドが起きてるとか，どのスレッドが止まってるとか丸分かり。さらにスレッド一覧の右端には，スレッドの停止・再開ボタンが付いているので，興味ないスレッドは先やっててみたいなことができる（スゴイよね）。 さらにダメ押しなのが，ステップ実行中に他のスレッドがどこで停止しているかも見える！！（超スゲぇ） 緑色の矢印＆ハイライト行が現スレッドの実行位置で，歯車アイコンが他のスレッドの実行位置（停
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
