非同期と並列 / morrita - Message Passing
karino2 が 並列プログラムから見たFuture というビデオを作って公開していたので、引っ越しの荷造りをしながら眺めた。 長いのでここにざっくりとした主張をまとめると: Future/Promise (およびその後釜の async/await) は非同期プログラミングで callback hell にならない発明という見方をされているが、 そもそもなぜ callback hell が必要だったかの時代背景が十分に理解されていない。 背景の一つはブラウザ JavaScript のプログラミングモデルにシングルスレッド・ノンブロッキング(イベントループ)という制限があったから。 これは(特にフロントエンド開発者の間では)よく理解されている。 もう一つの視点は SEDA みたいなマルチスレッド・ノンブロッキング環境の必要性で、 こっちはいまいち広く理解されていないように思える。 結果とし
「強いメモリモデル」と「弱いメモリモデル」 - 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の示すメモリアドレスに対するストア命令を実行して
sync.WaitGroupの正しい使い方 - Qiita
Goroutineを複数使って並列で処理を行って、それがすべて完了したら次に進みたいとしよう。Goroutineの完了はそれを生成したgoroutineに通知されるわけではないので、メインのgoroutineは何らかのメカニズムを使って全員が完了するまで待って、全員が完了したら実行を再開する必要がある。 sync.WaitGroupは複数のgoroutineの完了を待つための値だ（Javaを知っていれば、java.util.concurrent.CountDownLatchによく似ている）。WaitGroupの値に対してメソッドWaitを呼ぶと、WaitGroupが0になるまでWaitはブロックされる（待たされる）。従って、やりたい処理の数だけWaitGroupの値をインクリメントしておいて、処理完了時にデクリメントすれば、Waitを呼んで処理完了を待っているメインのgoroutineは、
A fork() in the road を読んで.md
A fork() in the road を読んで.md A fork() in the road を読んで HotOS 2019 で Microsoft Research からの論文である．Unixの代表的なシステムコールであるfork()についての問題点を挙げている． 概要 fork()は最も基本的なシステムコールといっても良く，新しいプロセスを作るときに使われる．今回の論文の主張はfork()は1970年代のマシンではハックと呼べるものだったが，現代では過去の負債となっているというものでおり，カーネルから完全に取り除くべきであるというものである．ただし，ここでいうカーネルとはLinuxカーネルのことを直接指しているのではなく，著者の先行研究でのOSの実装のことを指している． 面白いのは，fork()は研究者にとっては研究を阻害するといったことや，教育者は歴史としては教えるべきだが最初
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://papers.freebsd.org/2002/jhb-locking_in_multithreaded_kernel.files/jhb-locking_in_multithreaded_kernel-paper.pdf
Condvar in std::sync - Rust
