タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
排他制御の基礎の基礎
はじめに システムに存在するリソースには同時にアクセスしてはいけないものが多々あります。身近な例を挙げると、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 の並列数を制限するオプ
並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その1「背景: クロック周波数の停滞とコア数の増加」 - Qiita
大学の授業で講義資料を作ったので，Qiitaにも展開しておきます． 背景: クロック周波数の停滞とコア数の増加 コンピュータはクロック周波数に同期して計算をします．おおむね1秒間にクロック周波数の数で示されるだけの数の機械語命令を実行できると考えると良いです．たとえばクロック周波数が1GHzであれば，1GHz=1,000MHz=1,000,000(百万)kHz=1,000,000,000(10億)Hzですので，1秒間に1,000,000,000(10億)個の機械語命令を実行できるというような感じです．もちろんこれは概算です． いわゆるヘネパタ本(J. L. Hennessy & D. A. Patterson: Computer Architecture: A Quantitative Approach, 6th edition. Morgan Kaufmann, 2017; 邦訳 中條・
2019年9月25日、東武東上線にトラブルが次々と起こった。人身事故やシカの衝突といった出来事が同日に発生。そのうえ「運行管理システム」まで不具合を起こした。原因は排他制御のバグで、導入19年目に初めて顕在化したものだった。影響は約5万4000人、遅延は最大6時間14分に及んだ。 「運転再開を見込んでおりません」。2019年9月25日、東武東上線成増駅の掲示板に出ていた文言がツイッターで大きな話題となった。 この日、東武東上線はダイヤの大幅な乱れにより、沿線各駅の構内は電車に乗れなかった人々であふれかえっていた。普通は「運転の再開時刻は未定です」などと赤い字で書かれた案内が出るが、成増駅では冒頭のように風変わりな表現となってしまった。運転再開の見通しが立たないことによる混乱ぶりがうかがえる。 東武東上線は同日、池袋－小川町駅間で運転を見合わせ、上下線で合計103本が運休。午後に最大で6時間
楽観的排他制御（楽観的ロック）とは、同時アクセスによるデータの不整合を防ぐ排他制御（ロック）の手段です。バージョン番号や更新日時を利用して、データを取得してから更新するまでの間、データが変更されていないことを確認することで整合性を保ちます。対照に悲観的排他制御（悲観的ロック）では、データを取得する際にロックをかけることで整合性を保ちます。 DynamoDBでは楽観的排他制御を実装できます。また、DynamoDBのトランザクションでは楽観的排他制御が採用されています。 DynamoDBで楽観的排他制御 AWS LambdaでDynamoDBのデータを更新する際に、条件付き書き込みを使用してバージョン番号で楽観的排他制御を実装してみます。 DynamoDBに商品テーブルProductを作成して次のデータを格納しておきます。 productName(PK) stock version Lambd
MySQL/Postgres におけるトランザクション分離レベル - Speaker Deck https://speakerdeck.com/mpyw/postgres-niokerutoranzakusiyonfen-li-reberu 上記からの続編です。 排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！ https://zenn.dev/mpyw/articles/rdb-advisory-locks 上記の記事を解説する補佐的なスライドとして，株式会社ゆめみの社内勉強会にて発表しました。
Kubernetes Meetup Tokyo #36のLT資料です。 https://k8sjp.connpass.com/event/196212/
はじめに この記事ではgoroutineおよび関連性の高いsyncパッケージの基本知識や使い方をまとめます。 Goの基本的な文法はざっと触れたが、「goroutine」、「WaitGroup」、「channel」、「Mutex」などの言葉を聞いて全く心配ないとは言い切れない人向けの記事です。 残念ながら、メモリやCPU、プロセスなどのOSに近いところまでは踏み入れません。 goroutineは簡単だとよく聞きますが、そもそも並行処理そのものが難しいので1つずつ理解してきましょう！ 本記事での動作確認環境は以下です。 Goでの並行処理 ネットワーク通信などで待ち時間の大きい処理を非同期に行いたい、直列で動作させる必要がない処理群を高速に終わらせたいなどを理由に並行処理を使うことが多いと思います。 Goではgoroutineと呼ばれる軽量スレッドを簡単に動かせます。 なぜ「軽量」か メモリ消費
はじめに 特に組み込み系開発者なら超絶便利でよく利用するので、ドはまりして必死の調査により理屈を覚えた人も多数いるであろうマルチスレッドプログラミング。今回は本件について出来るだけかみ砕いて説明したいと思います。 記事の主題は以下となります。 プロセス/スレッドってなに？ 排他制御ってなんで必要なの？ その他注意点や排他を減らす手段の紹介 プロセス/スレッドってなに？ プロセス: main関数で動くプログラム 以前ライブラリの説明をした際に、プログラムはmain関数や使用するデータによって実現すると記載させてもらいました。このプログラムを実行すると、このプログラムの情報が全てメモリ上に展開され、利用されます。この展開された情報をひとまとめにしてプロセスと呼んでいます。 実行されたプログラムのことをプロセスと呼ぶので、例えば同じプログラムを2回実行すると、2つのプロセスが出来ることになります
Go言語でMutexおよびRWMutexを使った排他制御について調べたのでまとめます。 RWMutexとMutex RWMutexによる書き込み用ロック RWMutexによる読み込み用ロック RLockとLock まとめ 参考文献 RWMutexとMutex Mutexを使ったLockは読み込み（Read）も書き込み（Write）も両方禁止できる。つまり他のゴルーチンがそのMutexによりLockされている資源を使いたい時は、直前のLockが解放されるまで待つことになる。 一方で、RWMutexはMutexの機能のほか、読み込み（Read）のみ許可するLockができる。 つまり、他のゴルーチンがRWMutexの読み込みロックされている資源を使いたいとき、書き込みについては待たされるが、読み込みだけであれば、直前のLockの解放を待たずに処理を実行できる。 つまり、RWMutexはMutex
今回使用するスプレッドシート 排他制御サンプル1 - 3種類の排他制御コードが入っています（ライブラリ元でもある） 排他制御サンプル2 - スクリプトロックをサンプル1からライブラリとして呼び出すコードだけが入ってる ※サンプルではcopypaste()というメインルーチンをそれぞれのルーチンから呼び出しています。 概要 LockServiceというクラスを使用するのですが、3種類のロックサービスがあります。必ず冒頭でロックを宣言して、その後指定秒数のロックを実施、最期に必ずロックをリリースするといった一連の手順が必要になっています（でなければタイムアウトするまでロックされっぱなしになります）。 指定秒数よりも前にスクリプトが終了した場合、待たされていた側は即時にスクリプトが実施されるようになります。逆に指定秒数以上待たされた場合にはエラーが発生しスクリプトの実行がキャンセルされます。 ロ
並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その2「スレッドと同期・排他制御」 - Qiita
大学の授業で講義資料を作ったので，Qiitaにも展開しておきます． この記事シリーズでは，並行・並列プログラミングについて，要(かなめ)となる同期・排他制御の役割をCとJavaを例に簡単なプログラム例を示します．次に同期・排他制御の問題点をCのプログラム例とともに示します．そしてElixir(エリクサー)によって実現されている，全てをイミュータブルにすることによる利点について示します． シリーズ 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その1「背景: クロック周波数の停滞とコア数の増加」 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その2「スレッドと同期・排他制御」(本記事) 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その3「同期・排他制御の2つの問題点」 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その
SQLAlchemy とは SQLAlchemyは Python の ORM で、リレーショナルデータベースをオブジェクトとして扱うとこができるライブラリです。 SQLite、MySQL、PostgreSQL、Oracle などのデータベースに使用することができます。 導入するメリットとしては、 SQL を直接記述することなく、Python オブジェクトとしてデータベースを操作できる データベースの種類によらず、同一のソースコードで複数のデータベースを併用することができる SQL インジェクション対策がサポートされている などが上げられます。 今回は SQLAlchemy と MySQL を用いて、悲観的・楽観的排他制御を実装していきます。 環境 SQLAlchemy を使用するには、以下のインストールが必要です。括弧内は今回使用したバージョンです。 Python (3.7.3) データベ
1. はじめに 新人に悲観ロックによる排他制御を説明する際、実際にPostgreSQLを操作して見せたデモの評判がよかったため、今回Qiitaの記事にしてみました。排他制御は並列実行のイメージが掴めないと知識だけで理解するのは難しいので、体験してみると多少は理解しやすくなるかと思います。 なお、排他制御の説明については、他の方の良い記事やWebサイトがあるのでそちらを参照ください。 排他制御のあれこれ データベースさわったこと無い新人向けトランザクション入門 TERASOLUNA5.xのガイドラインの6.4. 排他制御 2. 悲観ロックを試してみる 2.1. 事前準備 今回は「PostgreSQL 9.3」を利用して悲観ロックを試してみます。 PostgreSQLのインストールについては他の方の記事を参考にしてみてください。 Windows環境でPostgreSQL 新人研修用（DB編）
はじめに アプリケーション開発において、ユーザーが入力したデータを永続化するにはDBを利用して実現するのが、スタンダードでしょう。 そして、DBを適切に扱うには、排他制御と言う概念を把握することが重要です。 では、排他制御とは何でしょうか？ 排他制御を辞書で引いてみると、適切に用語を解説してくれているページがありましたので、引用します。 《exclusive control》同時に複数のユーザーがアクセスできるファイルやデータベースにおいて、一方が処理中の場合、他方のアクセスを制限すること。それによりデータの整合性を保つ。ロック。 goo辞書 - 排他制御 引用した通りの内容ではありますが、排他制御は、同時にアクセスがあった場合にデータの整合性を保つために必要なものです。 ”データの整合性が保たれている”と言う事は、アプリケーションが想定したデータ構造になっている事を意味しますし、逆に”デ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![Google検索を殺した男――Googleはいつ、どこでメタクソ化に舵を切ったのか | p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/4daf0a0787400227544a080cbf566e75f4290bdf/height=288;version=1;width=512/https%3A%2F%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2024%2F04%2Fgoogle-enshittifier.jpg)
![なぜGoogleは“あなたの不満”を無視できるのか | p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/df1fbcfb853756284b40841e70fc320268975ba8/height=288;version=1;width=512/https%3A%2F%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2024%2F04%2F04Apr2024.jpg)
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
排他制御を行う GitHub Action を作った
システム障害が帰宅ラッシュを直撃、東武東上線を止めた「排他制御」のバグ
AWS DynamoDBで楽観的排他制御（楽観的ロック）をやってみた | DevelopersIO
排他制御のためだけに渋々 Redis 使ってませんか？
アプリのコンテナ化と排他制御 ~ データ 破壊 だ ﾖ 全員集合
【Goのやさしい記事】goroutineと排他制御を10分で入門しよう！ - Qiita
マルチスレッド、排他制御ってなに？ - Qiita
Goによる排他制御 ~ RWMutexによるRLockとLock - おひとり
排他制御でGoogle Apps Scriptを安全に実行【GAS】 🌴 officeの杜 🥥
SQLAlchemy で悲観的・楽観的排他制御 - Qiita
新人に悲観ロックによる排他制御を体験してもらう - Qiita
Webアプリケーション開発における、楽観的排他制御・悲観的排他制御のまとめ - Qiita
fukuumedia.com
esusokuhou.blog.jp
esusokuhou.blog.jp
esusokuhou.blog.jp
www.hanapress.com
esusokuhou.blog.jp