タグ: concurrency

ハンドラーの存在チェックは、あなたが思っているようなガードではありません。inbox テーブルに一意インデックスを張り、業務上の変更と同じ SaveChanges でマーカーを書き込み、勝者はデータベースに決めさせます。さらに、それを静かに台無しにする ExecuteUpdate の罠も扱います。

EF Core 11 にはいまだにロック用の API がありません。FromSql で実際の行ロックを取る方法を解説します。SQL Server では WITH (UPDLOCK, ROWLOCK)、PostgreSQL では FOR UPDATE、ロック範囲を静かに広げてしまうサブクエリの罠、NOWAIT と SKIP LOCKED、デッドロックのリトライ、そして行がまだ存在しない場合の対処法まで。

ハンドラーの「確認してから挿入」はアトミックではありません。SqlState 23505 の PostgresException を捕捉するか、全体を 1 つの INSERT ... ON CONFLICT 文にまとめてください。EnableRetryOnFailure は役に立ちません。

スレッドはプロセス内の他のすべてのスレッドとメモリを共有しますが、Dart の isolate は共有しません。isolate は自分のヒープを所有し、単一のイベントループを回し、他の isolate とはメッセージだけでやり取りします。VM レベルでそれが何を意味するのか、isolate group がどこで境界を曖昧にするのか、そして Flutter、FFI、web でどう現れるのかを解説します。

EF Core 11 に rowversion の同時実行トークンを追加します。[Timestamp] と IsRowVersion による設定、EF が実際に発行する SQL、DbUpdateConcurrencyException の捕捉、データベース優先 vs クライアント優先 vs マージ、ETag を使った切断された API、そして保護を無言で無効化する 5 つの落とし穴。

C# でクリティカルセクションを保護する 4 つの方法と、その選択のための判断マトリックス。.NET 9+ での同期的な相互排他には System.Threading.Lock を、セクションが await をまたぐ場合は SemaphoreSlim を、Wait/Pulse が必要な場合のみ Monitor を使います。

C# でスレッドプールに作業を投げる 3 つの方法と、どれを選ぶべきか。ほとんどの場合は Task.Run を、アロケーションのない fire-and-forget には ThreadPool.QueueUserWorkItem<TState> を、LongRunning やカスタムスケジューラーのときだけ Task.Factory.StartNew を使います。

async/await では足りないとき: Dart の isolate を起動して CPU バウンドな処理を UI スレッドの外で実行します。Isolate.run、Flutter の compute、SendPort/ReceivePort を使った長寿命ワーカー、境界を越えられるもの、そして JS/web での注意点。Dart 3.11 と Flutter 3.27.1 で検証済みです。

System.Threading.Lock は .NET 9 で登場し、.NET 11 と C# 14 では既定の同期プリミティブです。本ガイドでは lock(object) からの移行、EnterScope の動作、await・dynamic・ダウンレベル ターゲットにまつわる落とし穴を解説します。

System.Threading.Channels は .NET 11 における BlockingCollection の async ファーストの代替です。本ガイドでは、移行方法、bounded と unbounded の選び方、そしてデッドロックなしでバックプレッシャー、キャンセル、グレースフルシャットダウンを扱う方法を示します。