「強いメモリモデル」と「弱いメモリモデル」 - yamasaのネタ帳
Apple M1についての面白い記事を見かけて、久しぶりにメモリモデル屋(?)の血が騒いだのでブログを書く。 note.com 強いメモリモデル 現代のCPUアーキテクチャでは、x86(64bit, 32bitどちらも)が「強いメモリモデル」を採用しており、それ以外のメジャーなCPUが「弱いメモリモデル」を採用している。この「強いメモリモデル」「弱いメモリモデル」について、まずおさらいしておこう。 以下のように、2つの変数a, bに対して異なるCPUコアが同時にアクセスしたとする。 int a = 0; int b = 0; CPU1: a = 1; b = 1; CPU2: int r1 = b; int r2 = a; (上記はC言語に似た疑似コードを用いているが、実際は機械語命令になっていると考えてほしい。つまり、CPU1は変数a, bの示すメモリアドレスに対するストア命令を実行して
アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件 - blog.nomadscafe.jp
もっと詳しい方のフォロー募集です アプリケーションがマルチスレッドになってもネットワーク処理が分散されなければマルチコアを活かせない典型的な例です。id:viverの古橋さんがs100kpsとしてあげていた件にも近いかも。 memcachedで現象を確認します。最近のmemcachedはマルチスレッドで動くようになっているので、まずはそれを確認します。 $ memcached-tool localhost stats|grep threads threads 4 スレッドが4つで起動しています。 負荷がそれなりにある状態(8000req/sec程度)で、コマンドラインでtopを開き、「1」キーを押して、CPUごとの使用率を表示します。(例はFedora8 kernel-2.6.23) Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0
ABA問題 - Wikipedia
この記事には参考文献や外部リンクの一覧が含まれていますが、脚注による参照が不十分であるため、情報源が依然不明確です。適切な位置に脚注を追加して、記事の信頼性向上にご協力ください。（2023年1月） ABA問題（英: ABA problem）とは、マルチスレッドプログラミングにおいて同期化の過程で発生する問題であり、ある記憶域を二回読み出し、二回の読み出しが同じ値であることを「変更がない」とみなすことにしたとき、二回の読み出しの間に別のスレッドが値を変更し、他の作業を行った後また元の値に戻すと、最初のスレッドが誤って「変更がなかった」とみなしてしまうというものである。 ABA 問題は、複数のスレッドや(or プロセス)が共有されたメモリにアクセスする場合に生じる。下記のイベントの流れは、ABA 問題を発生させる。 プロセス が共有メモリから値 A を読み出す はプリエンプトされ、プロセス が
Omicron 同期プリミティブ
同期プリミティブ 同期プリミティブで最も重要なことは，実行単位から見て処理がアトミック(不可分)であることである．OS は他のタスクに処理が中断されることがないプリミティブを提供するし，(共有メモリ型)マルチプロセッサを考慮したプロセッサは実行サイクルが不可分である命令を提供する．つまり，クリティカルセクション内では，それぞれ一つのタスク，もしくはプロセッサだけが実行可能になるよう排他制御される． タスク間の同期 セマフォ，ミューテックス，スピンロック，モニタ，select (Unix) など． プロセッサ間の同期 古典的には TAS (Test-and-Set) または TSL (Test-and-Set-Lock)と呼ばれるプリミティブが提供されてきたが，最近のプロセッサではロックフリーなアルゴリズムをサポートするために CAS (Compare-and-Swap) や ll/sc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Javaプロセスの中でCPUを浪費しているスレッドを特定する - Qiita
