atomic operation どころか mutex もわかってなかったという話 2011-09-05 - 兼雑記
read write lock ってものがあります。 pthread だと pthread_rwlock_t 。コレの私の思ってたセマンティクスは以下のようなもんです。 writer lock を取ると普通の mutex lock みたいな感じ。その thread が unlock するまで、以降の reader lock と writer lock は block する。 reader lock を取ると、それ以降の writer lock は block する。 reader lock は block せずに取れる これは glibc の pthread のデフォルトの挙動なんですが、これは変えられるし、 POSIX によると環境によって違う挙動をすることもあるらしい、ってのを知りませんでした。 どういう時の挙動が変わるかというと、 reader lock が取られてて、 writer
スピンロック - Wikipedia
この項目では、計算機科学におけるスピンロックについて説明しています。核磁気共鳴におけるスピンロックについては「交差分極」をご覧ください。 スピンロック（英: spin lock, spinlock）[1]とは、計算機科学におけるロックの一種で、スレッドがロックを獲得できるまで単純にループ（スピン）して定期的にロックをチェックしながら待つ方式。スレッドはその間有益な仕事を何もせずに動作し続けるため、これは一種のビジーウェイト状態を発生させる。獲得されたスピンロックは明示的に解放するまでそのまま確保されるが、実装によってはスレッドがブロック（スリープ）したときに自動的に解放される場合もある。 スレッドが短時間だけブロックされるならば、スピンロックは効率的であり[2]、オペレーティングシステムのプロセススケジューリングのオーバーヘッドを防ぐことにもなる。このため、スピンロックはカーネル内でよく使
ThreadとHashMapに潜む無限回廊は実に面白い？ (1/3) - ＠IT
ThreadとHashMapに潜む無限回廊は実に面白い？：現場から学ぶWebアプリ開発のトラブルハック（10）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） マルチスレッドのトラブルハックはさっぱり分からない… 対処が難しいトラブルといえば、GC（ガベージ・コレクション）とマルチスレッド処理に起因することが多い。 前々回（「肥え続けるTomcatと胃を痛めるトラブルハッカー 」）と前回（「JavaのGC頻度に惑わされた年末年始の苦いメモリ」）の2回にわたってGC、特にメモリ周りのトラブルを取り上げた。そこで今回は、マルチスレッド処理のトラブルの1つ、「レースコンディション（競合状態）
ithreads でスレッドプール - naoyaのはてなダイアリー
マルチスレッドなサーバー実装を色々模索していて、Perl の ithreads で遊ぶ。ithreads は Linux の pthread にリンクさせた perl なら一応 NPTL で動いてくれるので、pthread アプリケーションの設計を試すのにも良い。 試しににやってみたのは、たとえば mod_perl とかで重い SQL でブロックするのが嫌なときとかにそれを別プロセスに丸投げしてやる、その丸投げされる側のサーバー実装。(やりたいことだけに関して言うと、TheSchwartz に似てる) クライアントとサーバーの IPC は UNIX ドメインソケット メッセージングのプロトコルは JSON サーバーはクライアントからのリクエストをバッファリングしたら、SQL を実行する前にクライアントとの接続を切断 この時点でクライアントは制御が戻る サーバーは内部ではフロントエンド /
第19章 スレッド
rubyスレッド スレッドは「みんな一斉に動く」というのが建前だが、実際には少しの時間ず つ順番に動いているわけだ。厳密に言えばマルチCPUのマシンでそれなりに工 夫すれば同時に二つ動いたりもできるが、それでもCPUの数以上のスレッドが あればやはり順番に動かなければならない。 つまりスレッドを作り出すためにはどこかで誰かがスレッドを切り替えてやら ないといけないわけだが、その手法には大きく分けて二種類ある。 カーネルレベルスレッドと ユーザレベルスレッドだ。これはどちらも読んで字の如く、ス レッドというものをカーネルで作るかユーザレベルで作るかという違いである。 カーネルレベルならマルチCPUを生かして複数のスレッドを同時に動かしたり もできる。 ではrubyのスレッドはどうなのかと言えば、これはユーザレベルスレッドで ある。 そして（それゆえ）同時に動けるスレッドは厳密にただ一つと制限
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
軽量スレッドブームだと思うので、そこらへんの情報をまとめてみる - 金利0無利息キャッシング – キャッシングできます - subtech
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Multi-threaded perl vs. Single-threaded perl - Islands in the byte stream (legacy)
perl5 ithread についての個人的な見解。そして Coro について。(tokuhirom)より ithreads を有効にしてコンパイルするだけで perl インタープリタの速度が低下する[要出典] これをちょうど試そうと思っていたところなのだった。ナイスタイミング。 結論からいえば，シングルスレッドなperlはマルチスレッドなperlよりロード時間・実行時間共に10%ほど高速である。 以下詳細を記す。 まず，perlバイナリを2つ用意する。バージョンはパッチなしの5.10.0で，ビルド/実行環境はLinux 2.6.18-92.el5pae, gcc 4.3.2 20081007 (Red Hat 4.3.2-7)である。 sperl (single-threaded perl): $ ./Configure -des -Doptimize=-O3 -Dprefix=~/sp
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
Perlでスレッド処理を行うサンプル少し - ナマアシタノム
はじめに Hatena::Bookmark::24hのHTMLデータを生成する際にはてなブックマークの個別ページRSSを複数件取得するわけですが、取得処理を勢いで作ってしまったためにスレッド化されていなかったりします。 早い話が１件目のRSS取得→完了→解析→２件目のRSS取得→…のように直列動作させてしまっている状況です。これは効率悪そうです。 並列で複数のRSSが取得できれば処理時間の短縮になりそうですね。ちなみにPerlには並列動作を行う仕組みとしてスレッドが組み込まれているようで、今日はPerlでスレッド処理を行うための処理をメモしておこうかと思います。 注意 実験した環境はWindows XP(SP3)/ActivePerl 5.8.8(Build819)です。それ以外の環境では動作確認していません。 サンプル１：スレッド生成＆実行 概要 スレッドを複数個生成・配列(@threa
ActionScript Thread Library 1.0 (そうめん) - Spark project
(English page) ActionScript Thread Library 1.0 (そうめん) ActionScript Thread Library 1.0 (そうめん) は、タスクシステムと Java のスレッドモデルをベースとした疑似スレッドライブラリです。 複雑で冗長になりがちな、イベント処理や非同期処理、リアルタイム処理を、分かりやすくスマートに記述することを可能にします。 もちろん、割り込みやキャンセル、例外処理もバッチリです。スレッドを使って、イベントリスナー地獄から抜け出しましょう。 ダウンロード MXP パッケージ for Windows (Flash CS3) http://www.libspark.org/svn/as3/Thread/tags/v1.0/release/Thread-1.0-win.mxp MXP パッケージ for Mac OSX (F
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://1978th.net/tech/promenade.cgi?id=68