排他制御の基礎の基礎
はじめに システムに存在するリソースには同時にアクセスしてはいけないものが多々あります。身近な例を挙げると、Ubuntuのパッケージ管理システムのデータベースがあります。aptコマンドの動作によってこのデータベースは更新されるのですが、同時に2つ以上のaptが動作できたとすると、データベースが破壊されてシステムが危機的状況に陥ります。 このような問題を避けるために、あるリソースに同時に1つの処理しかアクセスできなくする排他制御というしくみがあります。排他制御はOSが提供する重要な機能の一つです。 排他制御が必要なケース 排他制御は直感的ではなく非常に理解が難しいのですが、ここでは比較的理解が簡単なファイルロックというしくみを使って説明します。説明には、あるファイルの中身を読みだして、その中に書いてある数字に1を加えて終了するincというという単純なプログラムを使います。
トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。
IPAのITパスポート試験申し込みシステムで個人情報が漏洩、原因は排他制御の欠落 | 日経 xTECH（クロステック）
情報処理推進機構（IPA）は2018年3月13日、ITパスポート試験の団体申し込みにおいて個人情報の漏洩があったと発表した。同試験を申し込んだ二つの団体の間で、互いの申込者の情報が漏れてしまったという。
Sidekiq による非同期処理を Redis の分散ロックで排他制御した話 - peroli Developer's Blog
MERY のサーバーサイドエンジニアの @saidie です。 MERY では画像アップロードや記事投稿による検索インデックス作成などなど、ユーザからのリクエスト起因で起こる時間のかかる処理の多くを非同期に行うことでレスポンスタイムの向上に努めています。また、重複した非同期処理が並行して走ることによる スループット の劣化を分散ロックを用いた 排他制御 で緩和する取り組みなども行っています。 MERY は Ruby on Rails を用いて開発されており、非同期処理には Ruby 製の フレームワーク である Sidekiq を採用しています。この記事では Sidekiq と Redis による分散ロックを使って、同一の非同期処理が(あまり)重複しないような MERY の非同期処理システムについてご紹介します。 Sidekiq Sidekiq はクライアントサー バモ デルのマルチスレッ
日本航空（JAL）は2016年4月6日、4月1日に発生した重量管理システムの障害について公表した。開発元から適用されたパッチの中に、キャッシュの排他制御を追加する設計変更があり、もともと実装されていたディスクの排他制御との間でデッドロックが発生したことが引き金になった。 システムはルフトハンザ子会社製 問題となった重量管理システムは、独航空大手Lufthansaの子会社である独Lufthansa Systems（LHS）製の「NetLine/Load」。乗客の人数や座席配置、貨物や燃料の量を基に重心を計算し、貨物の最適な搭載位置を算出して指示を出す役割を担う。JALのほか独LufthansaやカナダのAir Canadaなどが導入している。JALの場合、サーバーは東京都内のJAL拠点にあり、主要9空港からアクセスして業務に使っている。 JALは自社開発の重量管理システムをメインフレーム上で
弊社では 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 の並列数を制限するオプ
ファイル操作の排他制御といえば、以下のものが代表的です。 flockとロックファイル（ディレクトリ）式に大きく分けられます。 ロックファイル（ディレクトリ）を使う open関数 symlink関数 mkdir関数 rename関数 古いロックファイル（ディレクトリ）の削除 シグナルトラップ flockを使う flock関数 読込モード 追加モード 上書き・読み書きモード エラー処理 まとめてロックする タイムアウト ■ロックファイル（ディレクトリ）を使う 基本は単なる使用中の目印です。目印が無いときに入って、自分で目印を作り、操作が終わったときに消して出るだけですね。トイレみたい(^^) で、使用中なら何回かノックします。（せかすな〜） open関数 ファイルオープン関数でファイル作成。 1.ファイルが存在するか。 2.しなければ作成。 と２段階を要するので、その隙に他のプロセスが
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
データの同時更新を防ぐための排他制御
CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その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; 邦訳 中條・
Redisを使って排他制御するwrapperコマンド Redis-Setlock をPerlとGoで書いた - 酒日記 はてな支店
しばらく前に作って書きそびれていましたが、Yokohama.pm #10 でLTしたのでエントリもあげます。 Perl版 https://metacpan.org/release/Redis-Setlock Go版 http://fujiwara.github.io/go-redis-setlock/ LTのスライドはこちら ⇒ Redis-Setlockを書いたはなし なにをするもの? 「setlockコマンドのロック処理をRedisサーバで行うもの」です。 setlockはflockを使ってロックを獲得したら引数に渡されたコマンドをexecする、daemontools付属のwrapperコマンドで、cronでコマンド実行するときなど多重実行を制御する場合に重宝します。 flockだとホストをまたいだロック処理が行えないため、その部分をRedisを使った排他制御に置き換えたものを書いてみ
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
Promise での非同期処理時、排他制御を怠ったばっかりにバグを出してしまった、そんな経験ありませんか。私はあります。 スレッドを使う場合、Mutex や synchronized 等々、大抵排他制御を行うライブラリや構文などがセットでついてくるのだけど、Promise/A+ には無いので自前で制御する必要がある。 なので、Promise で排他制御が出来るライブラリを npm から調べ、めぼしい物二つをピックアップしてみた。 async-lock https://www.npmjs.com/package/async-lock 一番メジャーっぽいライブラリ。ダウンロード数も多い。 ロック取得時、key を指定する redis の key の set のように、key ごとに排他制御したい場合に便利 タイムアウトのサポート 待ち受けタスク数の上限のサポート インターフェイスが、acqui
排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
2019年9月25日、東武東上線にトラブルが次々と起こった。人身事故やシカの衝突といった出来事が同日に発生。そのうえ「運行管理システム」まで不具合を起こした。原因は排他制御のバグで、導入19年目に初めて顕在化したものだった。影響は約5万4000人、遅延は最大6時間14分に及んだ。 「運転再開を見込んでおりません」。2019年9月25日、東武東上線成増駅の掲示板に出ていた文言がツイッターで大きな話題となった。 この日、東武東上線はダイヤの大幅な乱れにより、沿線各駅の構内は電車に乗れなかった人々であふれかえっていた。普通は「運転の再開時刻は未定です」などと赤い字で書かれた案内が出るが、成増駅では冒頭のように風変わりな表現となってしまった。運転再開の見通しが立たないことによる混乱ぶりがうかがえる。 東武東上線は同日、池袋－小川町駅間で運転を見合わせ、上下線で合計103本が運休。午後に最大で6時間
排他制御のあれこれ - Qiita
この記事は、システムエンジニア Advent Calendar 2016 - Qiita の２３日目の記事です。 昨日は @yy_yank さんの 気負わず普通にテストしよう でした。 明日は @koduki さんです。 はじめに 複数ユーザが触るアプリケーションを作る場合、同時にデータが更新された場合の制御は避けては通れません。 この制御はスレッドセーフとか同時更新とか色々な観点で考えないといけないのですが、いまいちそのあたり自分自身の中できれいに整理できていませんでした。 なので、この機会に同時に更新される場合の排他制御について、自分なりに整理してみました。 まえおき 説明に使用する言語は Java です。 説明のためにシーケンス図っぽいものを使っていますが、 UML の厳密な定義には従っていません。図が描きやすいからシーケンス図を利用している、ってだけなので厳密な記法ルールに従ってい
排他制御 - Wikipedia
排他制御せずに i と i+1 という2つのノードを同時に連結リストから外す操作を行うと、結果として i+1 のノードが外れないという状態になりうる。 排他制御（はいたせいぎょ）とは、コンピュータ・プログラムの実行において、複数のプロセスが利用出来る共有資源に対し、複数のプロセスからの同時アクセスにより競合が発生する場合に、あるプロセスに資源を独占的に利用させている間は、他のプロセスが利用できないようにする事で整合性を保つ処理の事をいう。相互排除または相互排他（mutual exclusion）ともいう。最大k個のプロセスが共有資源にアクセスして良い場合を k-相互排除という。 換言すれば1つのクリティカルセクションに複数のプロセス（またはスレッド）が同時に入ることを防ぐことである。クリティカルセクションとは、プロセスが共有メモリなどの共有資源にアクセスしている期間を指す。排他制御の問題は
シェルスクリプトで排他制御したいケースがたまにあります。 「多重起動の抑制」「二重起動の禁止」などとされることもあります。よくやるのは pid ファイルを作成したりロックファイルを作成したりだと思いますが、「ファイルの有無」とか「プロセスIDのチェック」がどうも不安定に感じていました。ファイルシステムの排他ロックとか簡単に使えればいいのに…！ 調べてみると、flock(1) なんていう便利なものがあることがわかりました。 http://linux.die.net/man/1/flock http://luna2-linux.blogspot.jp/2011/08/flock.html 第二版 あえて、「singleton.sh を source することでスクリプトを排他制御する」という構成にこだわる。 # 利用者はこのファイルを source します _LOCK_FILE=$0.lock
排他制御の落とし穴を避けるインデックス設計
排他制御の落とし穴を避けるインデックス設計：Dr. K's SQL Serverチューニング研修（5）（1/3 ページ） SQL Serverは一般的にチューニング不要のデータベースと認識されている。しかし基幹系業務システムへの導入が進むにつれて、パフォーマンス・チューニングのニーズは急速に高まってきた。そこで本記事では、日本におけるSQL Serverコンサルタントの第一人者、熊澤幸生氏にSQL Serverチューニングのノウハウを語っていただくことにした。インタビュアーはSQL Serverへの造詣が深いITジャーナリスト、工藤淳氏が担当する。（編集部） 前回の記事「排他制御メカニズムから“待ち”原因を究明する」では、wait事象を引き起こす原因の中から排他制御について解説しました。ロックとラッチ、ロックの粒度、複数粒度でのロックとロックマネージャといったSQL Serverのアーキテ
背景 社内でデータベース研修が始まったため、いい機会なのでMacにPostgreSQLを入れて遊んでみました。 インストールはここを参照したら簡単でした。 研修はOracleの教科書で進んでいますがまあ基本的な概念は同じですね。 まとめてみると、どういうときにロック取得できないのかが意外と理解できてないことがわかりました。 行ロックの取得（select for update） Transaction A nsdb=# begin; BEGIN nsdb=# update hello set value = 'ngdesuyo' where num = 3; UPDATE 1 nsdb=# update hello set value = 'ngdesuyo' where num = 2; UPDATE 1
誰でも特技の1つや2つは持っているだろうが、私の特技は、誰かと話をしながらでも、原稿が書けるというものである。といっても、さすがに複雑な会話はできないが、「晩ご飯何食べたい？」「うーん、中華でいいかな」ぐらいの日常会話はキーボードの手を休めずに話すことができる。仕事に集中していても、生返事ではなくきちんと受け答えするという特技は、まあ家庭円満に一役買っているといってもいいだろう。 というわけで、今回のテーマは「マルチスレッド」だ。スレッドは、「細い糸」だとか「筋道」と訳されるが、その比ゆでは逆にイメージがつかみにくいかもしれない。プログラム全体よりも小さな「一連の処理」と端的にいった方がよさそうだ。マルチタスクの場合は「複数のプログラムが同時に実行されること」というような理解でいいが、マルチスレッドについては、取りあえずは「複数のプロシージャが同時に実行されること」と理解しておくといいだろ
こんにちは！エンジニアの柳村です。 今回は、いい感じに設計していると普段はほとんど使う場面はなさそうな排他制御(Swift)についての話 です。 Swift(iOS)で使える排他制御はざっとあげただけでもこれだけたくさんあります。 NSLock/NSRecursiveLock/NSConditionLockobjc_sync_enter(),objc_sync_exit()DispatchSemaphoreOSSpinLock/os_unfiar_lock(iOS10以降)pthread_mutexsemaphoreGCDのserialQueueとDispatchQueue.syncを使うこれらの排他制御の違いはなにでどういったときにどういったときにどれを使えばよいかといったことについて説明します。 結論長くなるので先に結論を言っておきますと そもそも同期処理はないほうがいいのでそうなるよ
第3回 マルチスレッドでデータの不整合を防ぐための排他制御 ― マルチスレッド・プログラミングにおける排他制御と同期制御（前編） ―
第3回 マルチスレッドでデータの不整合を防ぐための排他制御 ― マルチスレッド・プログラミングにおける排他制御と同期制御（前編） ―：連載.NETマルチスレッド・プログラミング入門（3/3 ページ） lockステートメントよりも低コストな排他制御 lockステートメントによるパフォーマンス低下を軽減するそのほかのアプローチとしては、.NET Frameworkのクラス・ライブラリで用意されている「Interlocked」と「ReaderWriterLock」というクラスを使用することもできる。そのクラスの仕様から、使用する機会は限定されるかもしれないが、それがフィットする場面では積極的に活用したい。次に、これら2つのクラスについて説明していく。 ■スレッドセーフな変数の操作を提供するInterlockedクラス lockステートメントは非常にコストのかかるオペレーションであるが、.NETに
【DB概論】DBMSに求められるもの（1）排他制御とACID属性：できるエンジニアになる！ ちょい上DB術・基礎編（2） デキるエンジニアになるためには、DB技術の基礎は必須です。本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。
第4回 デッドロックの回避とスレッド間での同期制御 ― マルチスレッド・プログラミングにおける排他制御と同期制御（後編） ―
第4回 デッドロックの回避とスレッド間での同期制御 ― マルチスレッド・プログラミングにおける排他制御と同期制御（後編） ―：連載.NETマルチスレッド・プログラミング入門（1/3 ページ） 連載目次 前回では、排他制御を導入することにより、複数スレッドからの同時アクセスによるデータの不整合を発生させないためのプログラミングについて紹介した。しかし、排他制御を行った場合には、今度は「デッドロック」という問題が起こり得る。 本連載の最終回となる今回は、このデッドロックについて、そして前回の冒頭で少し触れた、複数のスレッド間で同期を取りながら処理を進める「同期制御」のためのプログラミングについて解説する。 マルチスレッドで最も注意が必要な「デッドロック」 排他制御を行ううえで最も気を付けなくてはならないことがデッドロックである。デッドロックとは、アプリケーション内部で排他制御などによる競合が起
複数のスレッドから1つの変数にアクセスする際、システム側のスレッドスケジューリング次第で、予期せぬ書き換えが起こってしまう場合があります。その為、ある1つのスレッドが変数にアクセスしている際は他のスレッドをブロックする排他制御やスレッドの同期を行う必要があります。C++でJavaのsynchronizedメソッド/ブロックと同じような記法でクリティカルセクションを実装する方法の1つにboost::threadライブラリのmutexとconditionクラスがあります。 mutex クラスの使い方 スレッドの排他制御を実現できます。具体的な使い方は、mutexインスタンスをmutex::scoped_lockクラスのコンストラクタの引数に指定し、そのインスタンスを取得することでロックをかけられます。あるスレッドが上の処理を以ってmutexインスタンスにロックをかけた場合、その他のスレッドは再
楽観的排他制御（楽観的ロック）とは、同時アクセスによるデータの不整合を防ぐ排他制御（ロック）の手段です。バージョン番号や更新日時を利用して、データを取得してから更新するまでの間、データが変更されていないことを確認することで整合性を保ちます。対照に悲観的排他制御（悲観的ロック）では、データを取得する際にロックをかけることで整合性を保ちます。 DynamoDBでは楽観的排他制御を実装できます。また、DynamoDBのトランザクションでは楽観的排他制御が採用されています。 DynamoDBで楽観的排他制御 AWS LambdaでDynamoDBのデータを更新する際に、条件付き書き込みを使用してバージョン番号で楽観的排他制御を実装してみます。 DynamoDBに商品テーブルProductを作成して次のデータを格納しておきます。 productName(PK) stock version Lambd
以前、以下の呟きをしましたが、わりと古い方法を利用しているコードが散見されるので、Swift 3での同期処理(排他制御)についてまとめてみます。 getterはsyncでSwiftぽいロックになってて良いけど( ´･‿･｀)https://t.co/X2OrjyBmH7 で、Foundation.Lockを使わずにDispatchQueue.sync使おうという話があった。 https://t.co/77zzkNUGLj — mono( ´･‿･｀)🐶🍎📱⌚️ (@_mono) August 7, 2016 参考: Concurrent Programming With GCD in Swift 3 - WWDC 2016 - Videos - Apple Developer かつての方法 WWDCスライドのpp.120-123に載っているのでご覧ください。 WWDCで勧められていた
セマフォを使った排他制御
排他制御とは、あるメモリやある操作を、同時に複数のプログラムからアクセスあるいは実行させないようにするための処理です。 プロセス間で排他制御をするには、グローバル変数は使えません。グローバル変数はプロセスごとにもつものだからです。 共有メモリの１バイトをフラグとして使ったりすると、フラグを立てた瞬間に２つ以上のプロセスが同時に 走ってしまう危険性があります。ファイルを作成し、ファイルが存在するか否かをフラグに使っても同じような 問題があります。 セマフォとは以上のような問題点を解決するための仕組みです。セマフォはOSが用意するグローバルなフラグのようなもので、 そのフラグを待っているプロセスが複数あったとしても、セマフォから実行の許可が得られるプロセスを１つ に制限させることができます。 サンプルプログラムを考えます。このプログラムは親が500バイト共有メモリを作成します。 そして、for
Ruby/Railsでロックファイルによる排他制御 | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、鈴木です。 バッチ処理を作成する時に、気を付けなければならないことの一つに、排他制御があります。 排他制御を行なう方法はいくつかありますが、今回はロックファイルによる排他制御を行なうコードを考えます。 排他制御を忘れると 排他制御を忘れていると、 cron で定期的にパッチ処理を起動するように設定した。 前回起動されたバッチ処理がまだ終了していなかったので重複して起動された。 そんな状況は考慮していなかったので、バッチ処理中にエラーが発生した。データ不整合が発生した。 といったことになりかねません。 ロックファイルによる排他制御とは、以下のような手順で排他的に処理を実行する方法のことを言います。 バッチ処理の最初にファイルをロックする。（ File#flock() を使用します ） ロックに失敗したら、処理を終了する。（ or ロックが取得できるまで待機する ） 本来の処理を実
MySQL/Postgres におけるトランザクション分離レベル - Speaker Deck https://speakerdeck.com/mpyw/postgres-niokerutoranzakusiyonfen-li-reberu 上記からの続編です。 排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！ https://zenn.dev/mpyw/articles/rdb-advisory-locks 上記の記事を解説する補佐的なスライドとして，株式会社ゆめみの社内勉強会にて発表しました。
MySQL を使ってリレーショナルデータベースの悲観的・楽観的排他制御を試してみる - CUBE SUGAR CONTAINER
リレーショナルデータベースの排他制御は、複数のトランザクションが同時に同じリソース (テーブル・行) に対してアクセスしても内容の整合性が崩れないようにするために行うもの。 また、排他制御のやり方には悲観的と楽観的のふたつがある。 悲観的排他制御は、あらかじめ対象のリソースを自分以外のトランザクションから操作できないように排他ロックをかけることで処理をアトミックにして実現する。 それに対して楽観的排他制御では、リソースを操作する際にそれが別のトランザクションから変更されていないことをバージョン番号やタイムスタンプを使って確認することで実現する。 今回はこのふたつの排他制御について MySQL を使って試してみることにする。 尚、今回使用する環境は次の通り。 MySQL はバージョン 5.6.26 を使っている。 $ mysql -u root -e "show variables like
例えばサーバが２台あったとして同じ時間に全く同じ内容のcronスクリプトが実行されるとする、その処理がDBのバッチ処理など大きなコストを必要とするなら両方のサーバで実行されるのは無駄でしかないし場合によってはデータの不整合なども発生するかもしれない。そんな時はredis-mutexを使って排他制御を行うことができる。 なにはともあれredisをインストール ※Macの場合のインストール方法です $ brew install redisredis-mutexというgemをインストール。 $ gem install redis-mutex Successfully installed redis-mutex-2.1.1排他制御を行いたい部分をRedis::Mutex.with_lockブロックで囲むだけでOK、簡単ですね。 #!/usr/bin/env ruby require 'redis-
Webサーバ拡張における排他制御のパフォーマンスチューニング /performance_tuning_of_exclusive_control in_web_server extension
第10回ペパボテックカンファレンス～インフラエンジニアがもっとおもしろくできる！～ https://pepabo.connpass.com/event/69866/
Firebase Apple SDK 年間ダイジェスト: 2023年 / Firebase Apple SDK Annual Digest: 2023
第4回 デッドロックの回避とスレッド間での同期制御 ― マルチスレッド・プログラミングにおける排他制御と同期制御（後編） ―
第4回 デッドロックの回避とスレッド間での同期制御 ― マルチスレッド・プログラミングにおける排他制御と同期制御（後編） ―：連載.NETマルチスレッド・プログラミング入門（2/3 ページ） スレッド同士を協調動作させる「同期制御」 マルチスレッドは処理を並行して同時実行する技術であるが、場合によってはそのスレッド同士がタイミングを計って協調動作しなければならないときがある。このような制御を「同期制御」と呼ぶ。同期制御の実現にはいくつかの方法が用意されているが、ここでは代表的な手法であるWait／Pulse方式を使用した同期制御の方法を紹介する。 ■Wait／Pulse方式（Monitorクラス）によるスレッドの同期制御 同期制御を行うための便利な機能として、Monitorクラス（System.Threading名前空間）には、Wait／Pulse／PulseAllという静的メソッドが用意
5.4. 排他制御 — TERASOLUNA Global Framework Development Guideline 1.0.0.publicreview documentation
5.4.1. Overview¶ 排他制御とは、複数のトランザクションから同じデータに対して、同時に更新処理が行われる際に、データの整合性を保つために行う処理のことである。 複数のトランザクションから同じデータに対して、同時に更新処理が行われる可能性がある場合は、基本的に排他制御を行う必要がある。 ここで言うトランザクションとは、かならずしもデータベースとのトランザクションとは限らず、ロングトランザクションも含まれる。 Note ロングトランザクションとは データの取得とデータの更新を、別々のデータベーストランザクションとして行う際に発生するトランザクションのことである。 具体例としては、取得したデータを編集画面に表示し、画面で編集した値をデータベースに更新するようなアプリケーションで発生する。
排他制御メカニズムから“待ち”原因を究明する：Dr. K's SQL Serverチューニング研修（4）（1/3 ページ） SQL Serverは一般的にチューニング不要のデータベースと認識されている。しかし基幹系業務システムへの導入が進むにつれて、パフォーマンス・チューニングのニーズは急速に高まってきた。そこで本記事では、日本におけるSQL Serverコンサルタントの第一人者、熊澤幸生氏にSQL Serverチューニングのノウハウを語っていただくことにした。インタビュアーはSQL Serverへの造詣が深いITジャーナリスト、工藤淳氏が担当する。（編集部） 「何か動き方がヘンだな」「妙に遅くなったな」と思っても、すぐにパフォーマンス・チューニングに取りかかれる人は多くありません。私のようにパフォーマンス・チューニングを専門にしているエンジニアでさえ、毎日新しい疑問との追いかけっこですか
シェルスクリプトの一部を排他制御する必要があり、調べたところ、CentOS 5 以降なら、util-linux に含まれる flock コマンドを使えることがわかりました。オンラインマニュアルに典型的な使い方が書いてあり、これは、なかなか素晴らしいと思いました。最初に考えた人は、すごいなと思います。オンラインマニュアルからの抜粋です。 FLOCK(1) H. Peter Anvin FLOCK(1) NAME flock - Manage locks from shell scripts SYNOPSIS flock [-sxon] [-w timeout] lockfile [-c] command... flock [-sxon] [-w timeout] lockdir [-c] command... flock [-sxun] [-w timeout] fd DESCRIPTION
volatileで排他制御出来ると、いつから思ってた？ atomicやsynchronized使うべし - Qiita
volatileで排他制御出来ると、いつから思ってた？ atomicやsynchronized使うべしJava package test; import java.lang.reflect.Array; import java.util.ArrayList; import java.util.concurrent.atomic.AtomicInteger; public class Sync { private final int THREAD_NUM = 50; private final int COUNT_NUM = 1000; private static Sync instance = new Sync(); private int mCounter=0; private volatile int mVolatileCounter=0; private Object mSyncO
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
JALシステム障害、前週に追加の排他制御がデッドロックを誘発
排他制御を行う GitHub Action を作った
Perlの排他制御 (flock,open,symlink,mkdir,rename)
App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
Promise で排他制御を行う - Qiita
排他制御（楽観ロック・悲観ロック）の基礎 - Qiita
システム障害が帰宅ラッシュを直撃、東武東上線を止めた「排他制御」のバグ
flock(1)でシェルスクリプトの排他制御（Linux） - Qiita
Postgres の排他制御（行ロックとデッドロック）についてメモ - Qiita
第11回 初めてのマルチスレッドと排他制御入門（1/4） - ＠IT
明日から使えない！Swiftの排他制御 | Supership Tech Blog
【DB概論】DBMSに求められるもの（1）排他制御とACID属性
C++, boost::thread : スレッドの同期と排他制御 – mutex、conditionクラス
AWS DynamoDBで楽観的排他制御（楽観的ロック）をやってみた | DevelopersIO
Swift 3での同期処理(排他制御)の基本 - Qiita
排他制御のためだけに渋々 Redis 使ってませんか？
redis-mutexで排他制御 - HK's Weblog
Redisでバッチ処理を冗長化しつつ排他制御
排他制御メカニズムから“待ち”原因を究明する
シェルスクリプトで排他制御（flock）