RCU(Read Copy Update)をちゃんと知る（1）-1 ほんとの概要 - tkokamoの日記
はじめに ファイルシステムのrcu-walkを理解するためにRCUの勉強から始めようと思ったので書留ます。 RCUとはざっくりこんなものだ、と分かっている前提での記録です。 予想している流れとしては、 概要（概要）← 今回 Linuxでの実装 rcu-walk（RCUの応用先） と考えています。原稿も無いので、次回がいつになるかわかりません（社内勉強会でrcu-walkを語ろうと思っているので完遂はすると思われます） 今回は、wikipediaとかよんでで「？」となった当たりを捕捉。 RCUとは？ 図を用いた簡単な理解 複数のタスクで共有するデータの参照/更新をきちんと行う場合、大抵は適切に排他区間をロックによって設けてそれを実現します。 理想的には、タスク間で共有するデータの参照/更新をロックフリーで行えるとよいのですが、一般的にそのようなことを実現する方法は考えられていません。 しかし
Rust Atomic compare and swap 2018 editionのRISC-Vソース〜LLVMを添えて〜 - Qiita
僕「core::sync::atomic…。めっちゃ辛そうなところでエラー出るやん・・・」 僕「なんか納得いかんから調べたろ」 この記事 is 何？ Rust core libraryのcore::sync::atomic::Atomic*.compare_and_swap関数を解析した経過と結果を記したものです。それ以外のことは出てきません。 途中からLLVMに突入しますので、C++成分がそれなりに混じっています。RISC-Vのアセンブリソースコードも少々あります。RISC-Vのアセンブリは難しくないので大丈夫です。 今回、この記事に関わる調査を行ったおかげで、次の知見を得ることができました。 Rust標準ライブラリのソースコードリーディング勘所を少し Rust compilerとLLVMとの関係性を少し LLVMのコード生成処理を少し 一番大きかった収穫は、Rust言語処理系のソースコ
ARMプロセッサにおけるロックフリーなデータ更新 - Qiita
基本的な背景知識について一応説明。 マルチスレッドなシステムにおいて、複数のスレッドから同時に共有データへアクセスを行う際は注意が必要。 例えば複数のスレッドからデータの更新を行う場合、スレッドAがまずデータを更新し終え、次にスレッドBがデータを更新する、といった場合特に問題は発生しない。 ところがデータ更新処理がアトミックに行われていない場合、例えばスレッドAのデータ更新中にスレッドBが先に同じアドレスにあるデータを更新してしまった場合などに不整合が発生する。 よって一般的にはセマフォやミューテックスといったロックを利用する事で、各スレッドがデータを更新している間は他のスレッドからのアクセスを禁止するような設計にする。 ただし、ロックを取っている間他のスレッドは完全にブロックされ停止してしまうため複数のマルチスレッド/コアのシステム等では、これがパフォーマンスの低下に繋がる事もある。 そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
