マルチスレッド・プログラミングの道具箱
まえがき クラウド上の仮想サーバから手元のスマートフォンまで、いまや複数のCPUコアを搭載するマルチコアはどこにでもある環境になりました。ハードウェア側が並列(Parallel)・並行(Concurrent)処理に向けて急速に進化する一方で、ソフトウェア側つまりプログラミング言語の進化はさほど追い付いていません。並行処理記述の手軽さを求めた Go言語 や、マルチスレッド処理の安全性を重視する Rust言語 などが登場してはいるものの、「普通にプログラムを記述するだけで複数CPUコア環境で高速に走るプログラミング言語」は遠い夢物語のままです。 モダンなプログラミング言語や並列・並行処理ライブラリは、複雑で難解なマルチスレッド処理を直接記述しなくてすむよう、安全性・利便性の高い抽象化レイヤを提供します（例：Go言語のgoroutineとchannel、Rust言語の Rayonライブラリ）。し
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
排他制御の基礎の基礎
はじめに システムに存在するリソースには同時にアクセスしてはいけないものが多々あります。身近な例を挙げると、Ubuntuのパッケージ管理システムのデータベースがあります。aptコマンドの動作によってこのデータベースは更新されるのですが、同時に2つ以上のaptが動作できたとすると、データベースが破壊されてシステムが危機的状況に陥ります。 このような問題を避けるために、あるリソースに同時に1つの処理しかアクセスできなくする排他制御というしくみがあります。排他制御はOSが提供する重要な機能の一つです。 排他制御が必要なケース 排他制御は直感的ではなく非常に理解が難しいのですが、ここでは比較的理解が簡単なファイルロックというしくみを使って説明します。説明には、あるファイルの中身を読みだして、その中に書いてある数字に1を加えて終了するincというという単純なプログラムを使います。
トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。
弊社では GitHub のレポジトリ管理に Terraform GitHub provider を使用しています。 いちいち手元で terraform plan や terraform apply を叩くのは面倒なので、 GitHub Actions を利用することを考えました。 tf ファイルと現実のリソースとの不整合を避けるために、 これらのコマンドは排他的に実行する必要があります。 例えば terraform apply を実行している最中に terraform plan を実行することはできません。 ここで問題になってくるのが GitHub Actions のジョブ並列数です。 2020-12-30 現在、GitHub Actions は同時に 20 並列まで実行可能ですが、逆に並列数を制限できないという贅沢な悩みがあります。 一応 Matrix Build の並列数を制限するオプ
状態機械を合成してデッドロックを検出できる Go 言語パッケージを作ってみました - チェシャ猫の消滅定理
はじめに マルチスレッドで動作するプログラムの設計は難しい問題です。個々のスレッドの動作は単純に見えても、複数が並行して動作する場合の動作は組み合わせ論的に複雑になります。また、タイミングに依存する不具合は狙って再現することが難しく、通常の単体テストによる検出にも限界があります。 そんなとき、有効な手法がモデル検査です。システムの取りうる状態をあらかじめ網羅的に探索することで、「実際に動作させた際にごく低い確率で踏むバグ」であっても、動作させることなく設計段階で発見することが可能になります。 ところでちょうど先日、デッドロック発見器を自作するハンズオンに参加する機会がありました。内容は非常にシンプルなモデル検査器を実装するというもので、せっかくなのでそのときの成果物を Go のパッケージとしてまとめたものを以下に公開しました。 github.com 以下、このパッケージで何ができるのかを具
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
概要 マルチプロセスでレスポンスの処理を行う（1リクエストにつき1プロセスがレスポンスの処理を行う）PythonのWEBフレームワーク[1]でAPIサーバーを実装している際、各プロセスから一つのファイルにログを書き出しても、行が上書きされる・順番が前後するといった不整合がおきないのか、という疑問がわきました。（ファイルは各プロセスで独立にopenするものとします。） Pythonのロギングに関する公式ドキュメントには、「複数プロセスから1ファイルへのロギングはサポートしていないから別の方法で工夫しろ」と書いてあるのですが、別の記事では「書き込むログの長さが短ければ不整合はおきない」と記述されていたり、よくわからなくなったので自分で調べてみました。 結論としては、Python標準のloggingモジュールでログの長さが2,147,479,552(=0x7ffff000)バイト以下なら「原子性
はじめに 特に組み込み系開発者なら超絶便利でよく利用するので、ドはまりして必死の調査により理屈を覚えた人も多数いるであろうマルチスレッドプログラミング。今回は本件について出来るだけかみ砕いて説明したいと思います。 記事の主題は以下となります。 プロセス/スレッドってなに？ 排他制御ってなんで必要なの？ その他注意点や排他を減らす手段の紹介 プロセス/スレッドってなに？ プロセス: main関数で動くプログラム 以前ライブラリの説明をした際に、プログラムはmain関数や使用するデータによって実現すると記載させてもらいました。このプログラムを実行すると、このプログラムの情報が全てメモリ上に展開され、利用されます。この展開された情報をひとまとめにしてプロセスと呼んでいます。 実行されたプログラムのことをプロセスと呼ぶので、例えば同じプログラムを2回実行すると、2つのプロセスが出来ることになります
Concurrency is not very intuitive. You need to train your brain to consider what happens when multiple processes execute a certain code block at the same time. There are several issues I often encounter: Failing to recognize potential concurrency issues: It's not uncommon for both beginner and seasoned developers to completely miss a potential concurrency problem. When this happens, and the concur
1. はじめに 新人に悲観ロックによる排他制御を説明する際、実際にPostgreSQLを操作して見せたデモの評判がよかったため、今回Qiitaの記事にしてみました。排他制御は並列実行のイメージが掴めないと知識だけで理解するのは難しいので、体験してみると多少は理解しやすくなるかと思います。 なお、排他制御の説明については、他の方の良い記事やWebサイトがあるのでそちらを参照ください。 排他制御のあれこれ データベースさわったこと無い新人向けトランザクション入門 TERASOLUNA5.xのガイドラインの6.4. 排他制御 2. 悲観ロックを試してみる 2.1. 事前準備 今回は「PostgreSQL 9.3」を利用して悲観ロックを試してみます。 PostgreSQLのインストールについては他の方の記事を参考にしてみてください。 Windows環境でPostgreSQL 新人研修用（DB編）
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita
「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターン
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
排他制御を行う GitHub Action を作った
排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
Python(とGo)で複数プロセスから一つのファイルにログを書き込んでいいのか？
マルチスレッド、排他制御ってなに？ - Qiita
Handling Concurrency Without Locks
新人に悲観ロックによる排他制御を体験してもらう - Qiita