「pthreadサポート」の意味するところ - yohhoyの日記
ある処理系が “POSIXスレッド(pthread)標準をサポートする” とき、処理系（実行環境を含む）で担保すべき事項と、利用者（アプリケーションプログラマ）が守るべき制約についてメモ。 アプリケーションをプログラマの意図通り実行させるための、処理系／利用者間の責任分解点は「メモリ同期(memory synchronization)」により定義される。 利用者：複数スレッドからの少なくともどれか1つが書込操作となる変数アクセスの場合、“メモリ同期関数” を用いた排他制御により変数アクセスが同時に生じないよう保証すること。 全てが読込操作である変数アクセスの場合、複数スレッドからの変数アクセスを同時に行ってもよい。（そのようなコードを書いても、意図通り実行されることが保証されている。） 処理系：コンパイル時に最適化を行う場合でも、あるスレッド内での変数アクセス操作を “メモリ同期関数” 呼
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
軽量スレッドブームだと思うので、そこらへんの情報をまとめてみる - 金利0無利息キャッシング – キャッシングできます - subtech
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
has_many :bugs, :through => :rails: Thread safety for your Rails
Rails 2.2 marks the first release of thread safe Rails. But “thread safety” alone, without any context, doesn’t mean shit. When people say Rails is “thread safe” ( or otherwise ), they usually refer to the dispatching process of Rails. Before 2.2, Rails dispatching looked like : Long story short, Rails can now serve multiple requests in more than one ruby threads ( or native threads if you’re on J
Intelが並列化処理用ライブラリをオープンソース化 | エンタープライズ | マイコミジャーナル
Intelは24日(米国時間)、並列化処理用ライブラリ「Threading Building Block(TBB)」をオープンソース化すると発表した。ライセンスにはGNU GPLv2を適用、ソースコードはTBBの開発用に設けられたWebサイト経由で公開される。 TBBは、並列化処理を目的としたC++のテンプレートライブラリ。TBBを利用することにより、並列プログラミングにおけるスレッドの生成や処理の割り振りなど、マルチコア/マルチスレッドに最適化されたアプリケーションの開発を効率化できる。 今回公開されたTBB 2.0が対応するプラットフォームは、Intel製CPUを搭載したWindowsとMac OS X、Linuxの3種。ソースコードからコンパイルする場合、GCCなどIntel C++以外のコンパイラを使用できるほか、SolarisやPowerPC G5を搭載したMacintoshなど
L'eclat des jours(2007-05-30)
_ C 以前、Cについて話してた時、それまでアセンブリ（たって、PDPのアセンブリなわけだし、知らんけど）でUNIXを書いてたリッチーが面倒になったので（その時、トンプソンは面倒になってなかった）制御構造を持って、かつ、間接参照を簡単に記述できるプログラミング言語としてCを開発したっていうようなことを言ったら、「それまでアセンブリで書いてた」の部分に疑念を表明されてびっくりしたことがあったけど、今の感覚ってそんなものなのかな？ それはafter RISCだからそうなのか、それとも最初からアセンブリで書くって行為がたとえば、今となっては京都まで53次を歩いて行くというくらい常識外れなことに感じるっていう認識なのか、どっちなんだろう。 _ かっこいいリンク集 震源地 最初の反応 まねっこ かっこよさの検証つき setjmp/longjmpかっこいい カッコ悪いよ もともとはかっこわるいのに、見
プロセス、スレッド、ファイバ、タスク、ジョブ、違いを整理してみよう - Schi Heil と叫ぶために
まずは分かりやすいプロセスとスレッドから。 Windows や Linux などの汎用 OS 上のアプリケーションは一般にプロセスとして動作している。プロセスはプログラムの実行単位である。プロセスは1つ以上のスレッドと、ファイル、ヒープメモリなどのリソースで構成される。一方、スレッドは CPU 利用の単位である。スレッドはそれぞれが専用のスタックと CPU レジスタのコピーを保持するが、ファイルやヒープメモリは同一プロセス内の全てのスレッドで共有する。 スレッドのさらにサブセットがファイバである。スレッドとの違いは切り替え動作にありファイバのほうが軽いというメリットがある。プロセス、スレッド、ファイバの関係はこちらの説明が分かりやすかった。 プロセスはプログラム実行のための固有のメモリ空間を持っており、最も独立性の高い実行単位である反面、起動や切り替えに時間がかかるという特性を持っています
Concurrent.Thread
Concurrent.Thread is a JavaScript library providing user-level (virtual) thread. It does not modify any Web browsers and consists of 100% pure JavaScript. You can write multithreaded programs for your favorite browsers without any extensions.
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
Perlのithreads（iスレッド）に関するメモ
Perlのithreadsについて ithreadsに関する日本語のサイトがあまりないので、何か適当にメモっておきます。 基本 サンプル 留意点（重要な基本事項） できるだけ最新のPerlで使おう スレッドのコンテキスト スレッドと値 オブジェクトの共有 オブジェクトは二度（以上）死ぬ Windows上でのdetach 特別なサブルーチンCLONEについて マルチスレッドにおけるrand()の使用 スレッドにおけるシグナル処理 関連情報 モジュール その他 forkによるthreadsのエミュレート cond_timedwait なぜかスレッドの生成に時間がかかる時があるのですが… Thread::Queueについて CLONEサブルーチン マルチスレッドにおける再現性のある乱数列 Thread::TieをWIN32 with activeperlで使う スレッドが生きているかどうかのチェ
中里一日記: 弱参照キャッシュの罠
弱参照キャッシュの罠 Javaの弱参照をキャッシュに使いましょう、という話がよくある。しかしこの手を考えなしに使うと、罠にはまる。私がはまった。 キャッシュ対象を生成する操作で、大量のメモリを確保・解放したら、なにが起こるか？ あるときはなにも起こらない。あるときはガベージコレクションが起こる。起動後しばらくは前者であることが多い。起動からしばらくすると、後者がぼちぼちと起こるようになる。 ガベージコレクションは弱参照を消してしまう。 ということは、だ――キャッシュ対象Aを生成するときにB, C, D...が消されてしまい、その消されたBを生成するときにA, C, D...が消されてしまい…… という現象が起こる。しかもこの現象は、起動直後には起こらず、しばらく経ってから起こるようになる。 いったんこの現象が起こると、まるでスイッチが入ったように止まらなくなる。特に、複数スレッドでキャッシ
memologue - UNIX上でのC++ソフトウェア設計の定石 (2)
鉄則2: シグナルハンドラで行ってよい処理を知ろう sigaction関数で登録したシグナルハンドラで行ってよい処理は非常に限定されている 次の３つの処理だけが許されている 自動変数の操作 “volatile sig_atomic_t” 型の大域変数の操作 「非同期シグナルセーフ」関数の呼び出し これ以外の処理を記述しないこと！ 説明： シグナル受信時に何らかの処理を行うためには、シグナルハンドラと呼ばれる関数を用意し、それをsigaction関数でシグナル名と紐付けておけばOKです。しかし、シグナルハンドラ内で行ってよい処理は、上記の通り非常に限定されています。これを把握しないまま奔放なコードを書くと次のような現象が起き得ます： 問題1: プログラムがデッドロックする危険がある タイミングに依存する、再現困難なバグの原因となる デッドロックの発生が典型例だが、それ以外にも関数の戻り値不正
再入不可能な関数を C で実装する - いやなブログ
再入不可能な関数を C で実装する 一度実行したら二度と中身を実行できなくなる再入不可能な関数を C で実装してみます。通常、このような関数はシングルトンなどの静的なデータの初期化に使いますが、ここではデータについては考えないことにします。 static 変数をフラグに使う まずは最も単純な方法から見ていきます。次の関数は static 変数をフラグに使って再入を防いでいます。厳密に言えば関数そのものには入ってしまっていますが、ここで気にしないことにします。 void once(void) { static int entered; // 最初は 0 if (entered == 1) { // すでに入ったことがある場合は return; // すぐ出る } entered = 1; // 初回の場合のみ、何かを実行する } この方法はシングルスレッドのプログラムではうまく動きますが、マ
Matzにっき(2006-07-20) - The Problem with Threads
<< 2006/07/ 1 1. ミッフィー展 2. 弟家族 3. 冷蔵庫 2 1. 第一日曜日 3 1. [Ruby] Ruby on Railsトレーニング 2. 風邪 3. 地上波デジタル 4. [Ruby] るびま原稿 5. [Ruby] Web 2.0の挑戦者:プログラマフレンドリーなバグトラッキングシステム16bugs 4 1. [Ruby] トレーニング2日目 2. 六本木ヒルズ 3. [Ruby] Award on Rails 4. W-ZERO3[es] 5 1. 帰宅、校正 2. [Ruby] 「ブレイク直前のLinux」を思い起こさせるRubyのマグマ 6 1. [原稿] 『たのしいRuby』前書き 2. 「かわいそう」 7 1. 歯医者 2. Pickaxe2校正 3. 『情報処理』 4. [知財] Open Tech Press | 知的財産推進計画2006によせ
DeadLockInRuby
この記事ではRubyによるデッドロック検出時のエラーメッセージを説明する。 サンプル 以下のスクリプトを実行するとデッドロックが検出される。 #!/usr/local/bin/ruby -Ks require 'thread' q = Queue.new Thread.new do q.deq end.join このプログラムでは、メインスレッドはワーカスレッドの終了をThread#joinによって待っている。その一方でワーカスレッドはQueue#deqを呼ぶことでデータのエンキューを待つ。したがってどのスレッドも動けない。 この時、Rubyは以下のメッセージを表示して実行を中断する。 test>ruby dl.rb deadlock 0xf63c8: sleep:- - /usr/local/lib/ruby/1.8/thread.rb:318 deadlock 0x10d678: sl
型に対する const 修飾が read に関するスレッド安全を含意する，という性質 - Cry's Blog
ある型 T があって， T のオブジェクトが const 修飾されているならば，そのオブジェクトに対する(const_cast をはじめとする const 性除去の構文を除く)あらゆる有効式がそのオブジェクトに関してスレッドセーフである，っつー性質を考える． この性質は，言い換えると，あるスレッドが const 修飾された T のオブジェクト，もしくはそれへの参照・ポインタを持っていた場合，そのスレッドはどう頑張ってもそのオブジェクト，もしくはそのオブジェクトが直接・間接に参照するオブジェクトに対する (Readers/Writer Lock の文脈でいうところの) Reader にしかなれない，というもの． この性質は，さらに言い換えると， T に対する const 修飾が単に論理的な定数性だけではなくて厳密にビット列の定数性を保証する，というもの． C++ では，オブジェクトに対する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そろそろvolatileについて一言いっておくか
PTL - Portable Thread Library
Amazon.co.jp: Programming with POSIX® Threads (Addison-Wesley Professional Computing Series): Butenhof, David R.: 本
