Your SlideShare is downloading. ×
0
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Linuxカーネル解読室輪講@はてな 第6章
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Linuxカーネル解読室輪講@はてな 第6章

2,666

Published on

Linuxカーネル解読室輪講@はてな 第6章

Linuxカーネル解読室輪講@はてな 第6章

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,666
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 「Linuxカーネル解読室」輪講@Hatena第6章「同期と排他」
    松本一輝
    @KazkiMatz
  • 2. 排他処理の主体
    プロセスコンテキスト
    システムコール処理
    プロセススケジューリング
    ハードウェア割り込みコンテキスト
    割り込みハンドラ処理
    プロセススケジューリング(P-82)
    ソフト割り込みコンテキスト
    割り込みハンドラ処理
    ksoftirq
  • 3. 排他処理の主体と手法
    先発
     (独占中)
    プロセスコンテキスト
    (プリエンプションあり)
    ハードウェア
    割り込みコンテクスト
    ソフト
    割り込みコンテクスト
    後続
    • semaphore
    • 4. Pre-emption禁止
    • 5. スレッド同期
    プロセスコンテキスト
    (プリエンプションあり)
    Pre-emption禁止
    Pre-emption禁止
    ハードウェア
    割り込みコンテクスト
    N/A
    (ハンドラはCPU固有)
    N/A
    (ソフト割り込みをやり直す)
    CPUに対する
    割り込みの禁止
    N/A
    (ソフト割り込みは
    カーネルが逐次処理 P-75)
    ソフト割り込みの
    禁止
    ソフト
    割り込みコンテクスト
    Pre-emption禁止
  • 6. 排他処理の手法
    割り込み抑制系
    semaphore
    スレッド同期
  • 7. 割り込み抑制系(1)
    CPUに対する割り込みの禁止
    semaphoreが使えない場合に有効
    CPUで割り込みをマスクする(P-66、P-120)
    CPU依存資源の排他処理に利用される
    プロセスRUNキュー
    空きページ管理用リスト
    スラブキャッシュ空きリスト
  • 8. 割り込み抑制系(2)
    ソフト割り込みの禁止
    irq_enter() & irq_exit() (P-66、P-121)
  • 9. semaphore
    POSIXsemaphoreとして、システムコールで提供される
    カーネル内部でも独自に利用される
    待っている間、プロセスはsleepしている
    比較的時間を要する処理の排他に向いている
    プロセス間の同期に向いている
    #include <sys/types.h>
    #include <sys/ipc.h>
    #include <sys/sem.h>
  • 10. スレッド同期
    システムコール(API)としては提供されない??
    カーネル内部では随所で使われている
    プロセスはsleepしない(busy wait)
    色々ある
    Spin lock
    seqlock
    RCU
  • 11. Spin lock
    いわゆる悲観的ロック
    CPUのアトミックな操作命令に依存
    HTに配慮した実装
    OoOEへの配慮が必要(メモリバリア)
    ロック取得のたびに、キャッシュラインのフラッシュが発生する
  • 12. Spin lock 実装例(from Wikipedia)
    lock: # ロック変数。1 = ロック済み, 0 = ロックされていない
    dd 0
    spin_lock:
    moveax, 1 # EAX レジスタに 1 をセット
    loop:
    xchgeax, [lock] # アトミックにEAXレジスタとロック変数の値を交換
    # ロックには常に 1 が格納され、以前の値が EAX レジスタに格納される。
    test eax, eax # EAX 自身をチェック。EAX がゼロならば プロセッサのゼロフラグがセットされる。
    # EAX が 0 なら、ロックは解放状態から新たに確保されたとみなせる。
    # そうでなければ、EAX は 1 であり、ロックを獲得できていない。
    jnz loop # ゼロフラグがセットされていないときは XCHG 命令に戻る。
    # これはロックが既に他に獲得されていた場合で、スピンする必要がある。
    ret # ロックを獲得できたので、呼び出した関数へ戻る。
    spin_unlock:
    moveax, 0 # EAX レジスタに 0 をセット
    xchgeax, [lock] # アトミックに EAX レジスタとロック変数を交換
    ret # ロックを解放
    出典: http://ja.wikipedia.org/wiki/スピンロック
  • 13. Spin lockのコスト
    CPU#0
    L2
    L3
    L1
    CPU#2
    L2
    L1
    CPU#1
    L2
    L1
    CPU#3
    L2
    L1
    Main memory
  • 14. seqlock
    いわゆる楽観的ロック
    参照時にキャッシュラインのフラッシュは生じない(->スケーラビリティ向上)
    更新処理はspin lock等を用いて排他処理する
    更新の手順
    Spin lockを発動し
    シーケンスカウンタに1を加え
    更新処理を行い
    シーケンスカウンタに再度1を加え
    Spin lockを解除する
    参照の手順
    シーケンスカウンタ値を記録し(奇数の場合はretry)
    参照処理を行い
    シーケンスカウンタを再度確認する(最初と違う値の場合はretry)
  • 15. RCU
    Read-Copy-Update
    リソースにロック変数を準備しない手法(->参照時の変数チェックが必要ない)
    更新の遅延処理が可能
    コピーGCの発想に近い?
    更新処理はspin lock等を用いて排他処理する
    更新の手順:
    Read&Copy 元データの構造体をコピーして新しいデータを作る
    Update 元データへの参照(ポインタ)を新しいデータに向ける
    元データを参照しているスレッドが無くなったと判断されたら(※)元データをGCする
    ルール
    「読み手はRCUクリティカルセクションでは絶対にコンテキストスイッチしてはいけない」
    IP routing tableの更新等に利用
    更新には(かなり)時間がかかる(全プロセスが一通り起床するまで?)
    ※各CPUがRCUクリティカルセクションを抜けたかどうかは、カーネル内のCPUビットマップにより管理されている。
    スケジューラからRCUがコールバックされるので、各CPUがビットマップ上のRCU状態フラグを都度更新する。
  • 16. 以上

×