Linux 備忘録 ： Ext3 のジャーナルファイルの再作成の方法
1. まず始めに Ext3 上でファイルシステムの破損状況を調査する umount /dev/hda1 e2fsck -fn /dev/hda1 正常時 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/hda1: 150/4308992 files (10.7% non-contiguous), 3486771/8614848 blocks Parallelizing fsck version 1.20-WIP (17-Jan-2001)
牛が牧草を食うのが共変継承なのか？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
Eiffelというプログラミング言語での話ですが、「反変（contravariant）の継承（反変規則による継承）」と「共変（covariant）の継承（共変規則による継承）」という奇妙な概念とそれに関する議論があります。 http://www.cs.purdue.edu/homes/bahmutov/cs510/eifell.html -- 反変／共変の議論 http://www.faqs.org/faqs/eiffel-faq/ -- Eiffel FAQの全体 http://www.geocities.co.jp/SiliconValley/8632/EiffelFAQ.html#LCON -- 日本語訳だが読みやすくない（機械翻訳？） 「牛は草食動物のサブクラス」なんて、僕が嫌がる例が出てきて（「僕は、オブジェクトもthisもサッパリ理解できなかった」を参照）、それでウンザリなんだ
REST誤用が多い？ - ラシウラ
http://www.witha.jp/blog/archives/2006/03/rest.html 誤用促進例とは以下のようなものらしい: 「REpresentational State Transferの略語。HTTPリクエストに対してXMLをレスポンスとして返す。********WebサービスはRESTを採用しています。」 こういうことが起きるのは、まず先に（CGIのかわりかなんかで）「REST」という用語を使うように決め、そのあとで説明が必要になる状況が起きるからかな、とも思ったり。確かに典型例として用いられるAmazonやGoogleのREST型のサービスは、上記説明の条件は満たしてるけど、それは荒すぎる。これはあれだ。ちょっと前の、本田由紀本のキーワードを使ってはあちゅう主義的発言するのと似ているだろうか。 たしかに簡潔な説明は難しいけど、外から見てそれが本当にRESTful
SVGの行方は？/ PDF 千夜一夜: 2006年03月07日 アーカイブ
SVGの行方は？ アドビのCEO Bruce Chizenのインタビューを読んでいて気になったことを、もうひとつ挙げます。 それはSVGの行方です。 SVGは、Scalable Vector Graphicsの略で、W3Cが制定しているWebなどで使うためのベクトル・グラフィックスの標準です。2003年にV1.1仕様が勧告となっています。 ・SVG V1.1仕様 Scalable Vector Graphics (SVG) 1.1 Specification W3C Recommendation 14 January 2003 SVGには、フルセットの仕様のほか、携帯などで使うためのSVG Tiny、SVG Basicなどのサブセットの規格もあります。 ・SVGモバイル仕様 Mobile SVG Profiles: SVG Tiny and SVG Basic W3C Recommenda
仕事の心がけ
目次 はじめに こころとからだ 休息は大切 睡眠 夜型と朝型 眠るための儀式 食事を味わう 心の健康 無駄を無駄にしない工夫 誠実に 記録と計画 仕事の見積り 文章を書く、プログラムを書く 文章の書き方 日々の生活 習慣の力を借りる メモの取り方 整理・整頓 道具 書物 文房具 自分との調和、他人との協調 複数の仕事のコントロール 他の人と仕事する 残りの話題 読者のみなさんからのフィードバック ぜひ、感想をお送りください 更新履歴 リンク集 はじめに このページでは、 結城が仕事をする上で心がけていること、 心がけようとしていることをご紹介しています。 こころとからだ 休息は大切 仕事について書くのに、 「休息」から書きはじめるのは変でしょうか。 けれども私はそうは思いません。 私は、よい休息がとれているときにはじめて 充実した知的生活を営むことができるからです。 逆に、休息がきちんとと
JF: Linux Kernel 2.6 Documentation: io_ordering.txt
JF: Linux Kernel 2.6 Documentation: /usr/src/linux/Documentation/io_ordering.txt io_ordering.txt I/O 順序付け [プレインテキスト版] 原著作者: unknown 翻訳者: 川崎 貴彦 <takahiko(a)hakubi.co.jp> バージョン: 2.6.5 翻訳日時: 2004/05/04 幾つかのプラットフォームでは、いわゆるメモリマップト I/O は、弱く順序付け されています (ウィークオーダ)。このようなプラットフォームでは、デバイス上の メモリマップされたアドレスへの I/O 書込みが意図した順番に届くことを保証する のは、ドライバ開発者の責任です。これは通常、「安全な」デバイスもしくはブリッジ レジスタを読み込むことによりおこないますが、これは、読込みが投入される前に
2004-10-11
2chのマルチスレッドスレッドで興味深い議論があった。見ていただければわかるが、「C++でdouble checked locking(DCL)は安全か」という話題を、CPU毎に検討している。各CPUのmemory modelの話に立ち入った、楽しい議論だ。特に、リンクされている Double-Checked Locking, Threads, Compiler Optimizations, and More http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf なるScott Mayersさんのペーパーがイケてると思う。最近書かれたばっかり。ここを読んでいなかったら当分知ることはなかっただろうな。ラッキー。 というわけで本題も興味深いのだが、とりあえずスレッドの中でいくつか示された「DCLに代わる高速なシングルトンの実装方法」が実際どの程度
UNIX上でのC++ソフトウェア設計の定石 (4) - memologue
鉄則4: スレッドの「非同期キャンセル」を行わない設計にしよう スレッドの非同期キャンセルとは： あるスレッドが別のスレッドを即座に強制終了すること 単に「設計が楽だから」「シンプルになるから」という理由でスレッドの非同期キャンセルを使うのはやめよう 一見楽そうに、シンプルそうに見えるだけ。様々な問題を引き起こす可能性が。問題の詳細を把握しないまま、スレッドの非同期キャンセルを行う設計にしないこと！ pthread規格では、あるスレッドの処理を別のスレッドが強制的に中断することが許可されています。これを、スレッドのキャンセルと呼びます。 スレッドのキャンセルには次の二種類があります。 方式１： 非同期キャンセル(PTHREAD_CANCEL_ASYNCHRONOUS) キャンセルは即座に行われる 方式２： 遅延キャンセル(PTHREAD_CANCEL_DEFERRED) キャンセルは、スレ
UNIX上でのC++ソフトウェア設計の定石 (3) - memologue
鉄則3: マルチスレッドのプログラムでのforkはやめよう マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している状態」でfork*1を行うと、さまざまな問題を引き起こす可能性があります。「問題」の典型例としては、子プロセスのデッドロックが挙げられます。問題の詳細を把握しないまま、マルチスレッドのプログラムで不用意にforkするのはやめましょう！ 何が起きるか 実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。 void* doit(void*) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); struct timespec ts = {10, 0}; nanoslee
UNIX上でのC++ソフトウェア設計の定石 (1) - memologue
UNIXは、Windowsなどの“開発者に優しい”OSと比較すると、シグナルやスレッドの利用に関して制限事項が多いですが、それを知らずにアーキテクチャ設計および実装を行ってしまうケースが散見されます。これは、再現困難なバグの温床となるでしょう。 そこで、罠に嵌らないための「鉄則」を何回かに分けて書いてみようと思います。 鉄則1: シグナルの送受に依存しない設計にしよう 他プロセスおよび自プロセスに対し、非同期シグナルを配送して処理の流れを変える設計はやめよう 非同期シグナルとは、SIGUSR1・SIGUSR2・SIGINT・SIGTERM などの、killシステムコールによって生成・配送されるシグナルのこと 単に無視(SIG_IGN)するのは問題なし スレッドとシグナルの併用もやめよう 動作の予測が困難、デバッグが困難 説明： 同期シグナルとは、SIGSEGV,SIGBUS,SIGPIPE
アセンブラで遊ぶ時に便利なgdb設定 - memologue
アセンブラで遊ぶ時に便利な ~/.gdbinit を紹介します。まず ~/.gdbinit を次のように記述してください。 # # ~/.gdbinit # # .so を shlib コマンドで手動で読み込む # set auto-solib-add 0 # スレッド生成時のSIG32でブレークしない handle SIG32 nostop # ニモニック構文の選択 # set disassembly-flavor intel set disassembly-flavor att # フラグレジスタの可読化関数 define pf printf "eflags: %s%s%s%s%s%s%s%s%s (= 0x%08u)\n",\ $eflags & 2048 ? "O":"-",\ $eflags & 1024 ? "D":"-",\ $eflags & 512 ? "I":"-",\
或曰:2002年12月下旬
今週のミス。 二度と繰り返さぬよう、記録に残しておく。 _ アライメント アセンブラで書いたテスト用データ。 .align 4 これを忘れたために、えらい目に…。 _ 浮動小数点レジスタを使い切る VU1 MicroMode プログラミングの話。 複数行列で頂点ブレンディングするコードを書いている時のこと。 何も考えずに、ループ開始前に行列をレジスタに読み出すコードを書いたら、 VCL に「レジスタ使い切った」と怒られる。 31 本しかレジスタ無いのに、 行列まとめて読み出せば不足するが道理。 そもそも VU1 MicroMode では ローカルメモリからデータを読み出す積和演算 は Upper/Lower で同時実行できるから、 焦ってレジスタに置いておく利点はない。 そこで、 ループ中で行列を順に読み出しつつ計算を行うように書き直して対応。 それにしても VU0 MacroMode の
【インフォシーク】Infoseek ： 楽天が運営するポータルサイト
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
gccのx86インラインアセンブリに関して
GCCでインラインアセンブリを使用 する方法と留意点等 for x86 (1999〜2006年10回改訂、2006年1月22日注意を追加、最終更新日2006年5月27日) 文: A. SAITOH <s-akira at users.sourceforge.net> home ※システム名、CPU名は一般に開発会社の登録商標です。 以下の情報はあまり過度に信用しないで下さい。より正確な情報は、asやgccのinfoから得て下さい。 個々のプロセッサ命令の解説はここでは述べません。そのような技術資料は、インテルやAMDのウェブ サイトのdeveloper向けのページからpdf形式で入手できます。 以下の文及びプログラム例の運用結果に関して、筆者は一切責任を負いません。 参考文献 [0] D. Stancevic, K. Scheibler, J. Leto, Linux Assembly
スレッド
Ruby のスレッドは環境にあるスレッド機能を使うのではなく、ユーザレベルで 実装されている。また非常に移植性が高く、どんな環境でも動く。 またあまり知られていない機能だが Ruby には Call/CC という制御構造がある。 これは最初に実装されたのはschemeで、 「制御された関数越しgoto」みたいなものだ。この Call/CC はスレッドの機能を 使って実装されているので、ここに書くことにしよう。 スケジューリング スレッドは「みんな同時に動く」というのが建前だが、実際はプロセスと 同じく、少しづつの時間、順番に動いている。それでもちゃんと全部の スレッドが平等に動いているように見えるためには、どこかで動作中の スレッドから動作権を奪って、別のスレッドに主導権を渡してやる必要がある。 その時の主眼はふたつ、「いつ」「だれに」スレッドを渡すかだ。いわゆる スケジューリングである。
memologue - g++ でのスタック使用量の動的解析
Linux Memory Overcommitment の話とも関係するが、組み込み機器向けのプログラムを設計・実装する際は、たとえターゲットがMMU/仮想記憶を利用できるモノであるとしても、使用するスタック量の見積もりくらいはしておきたいと思っている。 UNIXではsetrlimit(2)で、スタック使用量をunlimitedにしてしまえば、スタック使用量の自主制限にひっかかってsegvすることはなくなる。ちなみに ulimit -s での制限は、Linuxであってもstrictに効く。しかし、物理的な限界は確実に存在するわけで、スタックのある領域にアクセスした時に物理ページに空きがなければ、プロセスはSIGSEGVで死ぬかSIGKILLで殺されてしまう。 C言語で書かれたプログラムであれば、再帰や関数ポインタさえ上手に処理(コーディング標準で制限など)できれば、コードを静的に解析して最
GNU Nana - memologue
GNU nana: improved support for assertion checking and logging in GNU C/C++ という、C/C++のデバッグライブラリがある。開発は1999年以降止まっている模様だが、「達人プログラマ」でも紹介されている、ユニークな考え方のライブラリです。日本語の解説はないようなので、少し書いてみよう。 GNU Nana 概要 GNU Nana は、 C/C++のassert関数を置換するためのソフトウェアである。 標準のassert関数や、プログラマがプロジェクトの度に書き起こす類似の関数(以下、表明関数とでもしましょう)は、次のような欠点を持つ。 ２つのバイナリが出来てしまう: 表明関数を有効にしたデバッグ版バイナリと、無効にしたリリース版バイナリ。 表明関数はコードを肥大させる(条件文や、エラーメッセージや etc...) 表明に
OBB vs AABB - Radium Software Development
iPhoneの一般修理店は予約なしでも来店できる？ 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
type punning と strict aliasing - memologue
/.JのGCC-3.4リリースの話題を追っていたら、GCC3では-O2で-fstrict-aliasingが有効だから注意せよというポスト(http://slashdot.jp/comments.pl?sid=175355&cid=537217)があった。 strict aliasing については、Radium Software Developmentさんが詳しい。これは気にしておいたほうがよさそうだ。GCCの -fstrict-aliasing の説明は次。 コンパイルされている言語に適用可能な別名規則（aliasing rule）のうち最も厳密なものをコンパイラが前提することを許します。これによって、 C（およびC++）では式の型に基く最適化を動作させることになります。例えば、ある型のオブジェクトが別の型のオブジェクトと同一アドレスに位置することは、それら2つの型がほとんど同一でない
マルチスレッドと共有変数 (続き) -- およびvolatile修飾の必要性 - memologue
複数のスレッドで変数を共有し、さらにその変数に対してread/writeの両方のオペレーションが行われるとき、その変数の操作は、上で書いたとおり、 read/writeともにmutexで保護するべき volatile修飾だけで済ませるのはNG mutexで保護するならvolatile修飾は不要 です。その根拠を、規格を引きながら見てみましょう。 The Open Group Base Specifications Issue 6 の 4.10 Memory Synchronization には、 Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thr
マルチスレッドと共有変数 - volatile?なにそれ。 - memologue
複数のスレッドから共有する変数(典型的にはグローバル変数)を操作する際、どんな注意事項があるか？という話題です。プラットフォームはPOSIXを仮定します。pthreadのお話です。 まず、一口に「複数のスレッドで変数を共有」といっても、おおまかにいって次のような状況が考えられます。 読むスレッドしか存在しない 読むスレッド、書くスレッドの両方が存在する 書くスレッドは、read-modify-write動作を行う 書くスレッドは、read-modify-write動作を行わない 変数の更新(メモリ操作)がアトミックに行える*1 変数の更新(メモリ操作)がアトミックに行えない*2 順に見ていきましょう。観点は、「(1) volatile修飾が必要か」「(2) mutexによるロックが必要か」の2点です。 まず、「1. 読むスレッドしか存在しない」ケース。例えば、 static const c
Threadのスタック - memologue
Linuxでpthread_create()をすると、生成されたスレッドにはそれ固有のスタック領域が割り当てられる。具体的にどのように割り当てられるのかを調査。 stack smash 対策を考える1場合、スタックの割り付け方を知っていると多少有益かもしれないので[securiy]カテゴリにも入れてみました。なお、exec-shield などの、address space randomize系パッチとの相互作用は未調査です。調べないとなぁ…。SELinuxで遊ぶ計画も延び延びだ。 NPTLのstack allocation手法 NPTLで、pthrad_create()時にそのスレッド用のスタックがどう割り当てられるか調査した。調査といっても nptl のソースコードを軽く読んだだけですが。 (1) スタックサイズ nptl/allocatestack.c を見るに、pthread_set
UNIXの規格について - memologue
いままで漠然と、「UNIXの規格について調べるときにはSUSv3を見る」ことにしていましたが、それでOKなのかちょっと調べてみました。 結論としては、ここ 今や ISO/IEC 9945:2002 IEEE Std 1003.1-2001 (POSIX) Single UNIX Specification Version 3 (SUSv3) の3つは，全く同じものですから、SUSだけ見れば十分だと思います。 の記述通りのようですね。 以下は、The Single UNIX Specification Version 3 - Overviewに書いてあることの要約です。 自分なりのまとめ 昔、似たような標準を作っている団体として、OpenGroup, ISO/IEC, IEEE があった。で、 ISO/IEC 9945-1(POSIX.1), ISO/IEC 9945-2(POSIX.2)
Linux Memory Overcommit - memologue
かなり昔ですが、或日さんのSolaris8におけるmemory over commitの話題に触発され、Linuxの場合について調べた事があります。正しさは保証しませんが当時のメモを貼っておきます。 memory overcommit? メモリ資源の非常に限られた環境でLinuxを使用しているとよく遭遇する現象なのだが、kernel 2.4までのLinuxでは、"mallocが成功を返したにもかかわらず、その確保した筈のメモリ領域にアクセスすると、SIGKILLによってkernelから強制終了させられてしまう" という現象が 発生することがある。これは、「全プロセスがnew/mallocしたメモリの総量」に対して物理メモリ量が少なすぎる瞬間に於いては常に発生し得る。 何に困っているかといえば、C++でオブジェクトをnewした時に、メモリの枯渇をstd::bad_alloc例外送出という形で
localtimeやstrtokは本当にスレッドセーフにできないのか (1) - memologue
googleから私の日記に、localtime_r や strtok_r, getpwnam_r などのキーワードで飛んでくる方が結構多いので、ちょっと関連する話題を書いてみます(内容の割に長い…)。 さて、8/9の日記で、POSIXのlocaltimeという関数(下記)を取り上げ、 struct tm *localtime(const time_t *timer); この関数を複数のスレッドが同時に使うと処理が破綻すると書きました。また、この関数はシグネチャが腐っているので、libcの外側でmutexを使っても処理の破綻を回避することはできず、localtime_rという代用関数を使うしかないとも書きました。POSIXで示されている代用関数(TSF)の一覧は、8/21の日記に書いた通りです。 本日は視点をちょっと変えてみて、「localtimeのシグネチャは本当にダメダメなのか？」に焦点
非同期シグナルとanti-pattern - memologue
sigsafeというUNIX向けの小さなライブラリがあります。これは、「シグナルを正確に取り扱うのは非常に難しい、俺たちのライブラリを使うと随分楽になるよ」といった趣旨の、アセンブラとCで書かれたライブラリで、それなりの種類のOS、CPUがサポートされています。 このライブラリ自体の使い方、使い勝手、あるいはどう実装されているかについてはまだ把握しきれていないのですが、ドキュメントに有用な部分があるのでご紹介します。 http://www.slamb.org/projects/sigsafe/api/patternref.html です。非同期シグナルを使用したコーディングを行う際の、一種のアンチパターン集になっています。 悪い例1: signal safe ではない関数をシグナルハンドラから呼んでしまう void unsafe_sighandler_a(int signum) { pri
memologue - UNIX上でのC++ソフトウェア設計の定石 (2)
鉄則2: シグナルハンドラで行ってよい処理を知ろう sigaction関数で登録したシグナルハンドラで行ってよい処理は非常に限定されている 次の３つの処理だけが許されている 自動変数の操作 “volatile sig_atomic_t” 型の大域変数の操作 「非同期シグナルセーフ」関数の呼び出し これ以外の処理を記述しないこと！ 説明： シグナル受信時に何らかの処理を行うためには、シグナルハンドラと呼ばれる関数を用意し、それをsigaction関数でシグナル名と紐付けておけばOKです。しかし、シグナルハンドラ内で行ってよい処理は、上記の通り非常に限定されています。これを把握しないまま奔放なコードを書くと次のような現象が起き得ます： 問題1: プログラムがデッドロックする危険がある タイミングに依存する、再現困難なバグの原因となる デッドロックの発生が典型例だが、それ以外にも関数の戻り値不正
g++ の -fthreadsafe-statics ってオプション知ってます？ - memologue
古来より、関数スコープの静的なオブジェクトを作るのは危険 void foo() { static CBar bar; // こんなの とされています。foo()が初めて呼ばれたタイミングでbarのコンストラクタが走るわけですが(C++規格でそう決まっている)、foo()の初回呼び出しが2つのスレッドでほぼ同時に行われると、barのコンストラクタが複数回走ってしまったりと、不可解な動作をすることが知られています。 参考サイト: http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx (引用するの何度目だろ) ところが、最近のg++には -fthreadsafe-statics っていうオプションがあって、この初回のコンストラクタ呼びをスレッドセーフに行ってくれるようになりました。手元のgcc3.4.3ではデフォルトでon
シグナルハンドラからのforkするのは安全か？ (1) マルチスレッドの場合 - memologue
マルチスレッドのプログラムが、(シグナルハンドラ以外から)forkするときに注意事項があることは既に書きましたが、「forkをシグナルハンドラの中から行いたい」というケースでは、さらに追加の注意事項があります。 一般に、シグナルハンドラでforkしてよいのは次の2つのどちらかの場合だけです。どちらも満たさないケース、例えば「フォークハンドラ*1関数内でprintfを呼んでいる」ケースではシグナルハンドラでのforkは安全ではありません。 pthread_atforkでフォークハンドラが登録されていない pthread_atforkでフォークハンドラが登録されており、その関数が非同期シグナルセーフ(async-signal-safe)である。つまり、規格で非同期シグナルセーフとされている数の関数しか呼んでいない関数である。 pthread_atforkとはPOSIXで定められている関数で、マ
memologue - C++でsynchronized methodを書くのは難しい (1)
Javaにはsynchronizedという便利なキーワードがあります。このキーワードを使うと、例えば次のように簡単にメソッドを「同期化」することができます。同期化されたメソッドは、複数のスレッドで同時に実行されることがありません。 public class Foo { ... public synchronized boolean getFoo() { ... } さて、C++ (with pthread) で同様の機能を実現するにはどうしたらよいでしょう？まず、一番単純な方法は次のようなものです。 // 方法 a void Foo::need_to_sync(void) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); // 処理 pthread_mutex_un
UNIX上でのC++ソフトウェア設計の定石 (6) - memologue
鉄則6: マルチスレッドプログラミングの「常識」を守ろう POSIXの標準関数のうち、非スレッドセーフであるものの一覧を把握し、使わないようにせよ 自作の関数はスレッドセーフにせよ 共有変数はロックして参照・更新せよ C++を使っているなら、関数を同期化する方法に注意せよ 説明: (1) POSIXの標準関数のうち、非スレッドセーフであるものの一覧を把握し、使わないようにせよ もしPOSIXプラットフォームでマルチスレッドのプログラミングを行うなら、いくらかの最低限の知識、つまり「常識」を知り、厳守する気持ちで望みましょう。 ...まずは、「スレッドセーフ」の意味を理解しましょう。スレッドセーフな関数とは、「複数のスレッドが同時に呼び出しても問題ない関数のこと」です。こういう関数は次のどちらかの性質を満たしています。 局所的静的変数(関数内のstatic変数)や非局所的静的変数(大域変数)
UNIX上でのC++ソフトウェア設計の定石 (5) - memologue
鉄則5: スレッドの「遅延キャンセル」も出来る限り避けて通ろう スレッドの非同期キャンセルとは：あるスレッドが別のスレッドに処理の中断を依頼すること 遅延キャンセルは、規格の自由度が比較的高いため、OSやCライブラリのバージョンにより動作がまちまち 環境によらず安定した動作を得るには、使用する環境の詳しい調査や、Cライブラリの抽象化作業、条件コンパイルなどが必要 C++では、「キャンセル発生時のオブジェクトの解体」を、移植性のある方法で実現できない 慎重に使用すること。C++では使用しないこと 説明: スレッドのキャンセルに「非同期」「遅延」の二種類があることはすでに述べた通りで、またこの「非同期キャンセル」が非常に厄介な数々の問題を引き起こす元凶であることも、既に述べました。 さて今回は「遅延キャンセル」を扱います。遅延キャンセルは、非同期キャンセルほど様々な問題は引き起こさないのですが
リード・コピー・アップデート - Wikipedia
リード・コピー・アップデート（read-copy-update、RCUと略記）とは、オペレーティングシステムにおいて一種の排他制御[note 1]を実装する同期機構であり、リーダー・ライターロック（英語版）の代替手段として使われることがある。参照において待ち状態が生じず、極めてオーバーヘッドが低い。しかしRCUにおけるデータ更新は、既存の参照者のために古い版のデータ構造を保持しつつ行うため、時間と空間（メモリ）をより多く必要とする。古い版のデータ構造は、既存の参照者が全てアクセスを完了した後で回収される。 概要[編集] RCUでは「参照側クリティカルセクション」という概念があり、通常 rcu_read_lock() と rcu_read_unlock() で挟まれた部分がそれにあたる。参照側クリティカルセクション内にない文は「不活性状態」と呼ばれ、RCUで保護されたデータ構造への参照を保持
GCC some extensions
gcc(Gnu C Compiler)の拡張文法 [警告!] C/C++言語初心者はこのページを読まないでください。 このページではgcc独自のC/C++拡張文法について解説します。 これらの拡張文法が可能にする機構は確かに便利なのですが、 もちろんANSI規格に従っていないので、一般的には使うべきではありません。 C/C++言語文法を学び始めている初心者はこれらgcc拡張文法を 知るべきではありません。C/C++言語を正しく理解する上で大きな 支障となります。 C/C++言語を十分に熟知した者は、gccがこのようなこともすることを 「雑談」として知っておくと楽しいかもしれません。もちろん 実戦に使うべきではありませんが。しかし初心者が偶然に、これらの 機能を使ってうまくいく場合がありますので、そのような初心者を 見つけたら、それが標準規格ではないことを注意してください。 配列変数をコピー
UNIXの落とし穴
UNIXを使っていて気づいた細かい不満を挙げます。他の人の意見も 混ざっています。もっと UNIX が嫌いになりたい人は Unix Hater's Handbook をどうぞ。UNIXをなんとかしたい人は Let's Make Unix Not Suck をどうぞ。 目次 設定ファイル地獄 変な文法 流儀の違い 貧乏くささ プログラミング 初心者の敵 X Window System その他 設定ファイル地獄 山のような設定ファイル ソフトウェアごとに異なる流儀を覚えるのむちゃくちゃ面倒。 まさに、しょうもない 雑多なノウハウ の山。 procmail の設定ファイル 変態的。 :0 ってなんだ? BIND の設定ファイル ドメイン名を書くレコードの最後に . をつけ忘れる。 シェルごとの .*rc .*profile .*login などの挙動の違い わけわからん。 /etc/sh
Valgrind Home
Information About News Tool Suite Supported Platforms The Developers Source Code Current Releases Release Archive Variants / Patches Code Repository Valkyrie / GUIs Documentation Table of Contents Quick Start FAQ User Manual Download Manual Research Papers Books Contact Mailing Lists and IRC Bug Reports Feature Requests Contact Summary Commercial Support How to Help Contributing Project Suggestion
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
２ちゃんねるネット : 彼氏の部屋でエロビデオを発見
或曰:2001年2月上旬 メモ／メモリ領域の確保
IBM Developer
http://home.catv.ne.jp/pp/ginoue/memo/lib-symbol.html