Linux Kernel: rtnl_mutex を長時間 ロックして刺さった状態を観察する - hibomaの日記
Linux Kernel で struct net_device や Routing Netlink の処理を排他制御する mutex である rtnl_mutex を任意の時間 ロックするカーネルモジュールを作成して、rtnl_mutex のロックがユーザランドのプロセスやカーネルスレッド等にどういった影響を及ぼすかを観察する ... というエントリです Linux カーネルの話や、strace, gdb, /proc/$pid/stack を使ったデバッグ方法に興味あるかた向けです 経緯 とあるサーバで動いてる大量のプロセスが rtnl_mutex をロックする箇所やそれに関連していそうな箇所で TASK_UNINTERRUPTIBLE でブロックしてしまい、障害を起こしているのに遭遇して原因を追いかけていたのでした 障害の再現が難しくて困っていたのだが、別のアプローチとして 「rtn
Rust のメモリーコンテナー的な何かをわかりやすく整理したチートシートのメモ; T, Cell, RefCell, AtomicT, Mutex, RwLock, Rc, Arc - C++ ときどき ごはん、わりとてぃーぶれいく☆
Repos: https://github.com/usagi/rust-memory-container-cs 作ったので GitHub ↑ しつつ、なんとなくすごい久しぶりに Qiita に初心者さんに優しそうな雰囲気を装った解説↓ https://qiita.com/usagi/items/fc329895cebd3466910e も書いてみました。ちなみに reddit ↓ https://www.reddit.com/r/rust/comments/idwlqu/rust_memory_container_cheatsheet_publish_on_github/ にもポストしてみました。 reddit はとても参考になる議論がおおむね建設的にものすごい勢いで発生してくれるので嬉しいです。チートシートとしての意図と図面の都合による nitpick たちは README に注釈を付
RustはGCのない言語なので、GCがあった時にふつうに書けていたコードが書けなくなります。その典型例はリスト・ツリー・グラフといった再帰的な構造です。 これに対してドキュメントや記事を読むと、以下のような型が出てきます。Haskellのモナドスタックの再来と怯える人もいるかも知れません。 enum List { Cons(Rc<RefCell<i32>>, Rc<List>), Nil, } pub struct NodeRef<T>(Rc<RefCell<Node<T>>>); type Link<T> = Option<Rc<RefCell<Node<T>>>>; type WeakLink<T> = Option<Weak<RefCell<Node<T>>>>; 大抵のドキュメントは、木構造を実装してみようというテーマで、上のような型がなぜ必要になるのか？を説明してから、そのマルチ
sync.Mutexの仕組みを理解する
Go Conference 2023 https://gocon.jp/2023/sessions/A14-S/
Send & Mutex – Cryptical
I saw a question on Reddit, that asks: “Why does T need to be Send for a Mutex to be Sync“. I think that’s a great question, and in here I’ll try my best to shine some light on that. Send & Sync (intro) These are two marker traits (or auto-traits) implemented automatically by the compiler, that are very important for coding in Rust. They indicate that a type is safe to use (access) between threads
Mutex without lock, Queue without push: cancel safety in lilos - Cliffle
2023-07-10 (updated 2023-07-12) Levels of cancel safety What good is a queue that you can’t push into? What good is a mutex you can’t lock? Toward a more cancel-safe world I’m trying to do something kind of unusual with lilos: in addition to almost all the APIs being safe-in-the-Rust sense, I’m also attempting to create an entire system API that is cancel-safe. I’ve written a lot about Rust’s asyn
yoh on Twitter: "個人的にはRustの型設計／制約こそがMutex lockに関する正解だと思ってる ほとんどの言語ではプログラマの責務が大きすぎる＝並行バグリスクが高いという感じ https://t.co/xYGHs1mjnJ"
個人的にはRustの型設計／制約こそがMutex lockに関する正解だと思ってる ほとんどの言語ではプログラマの責務が大きすぎる＝並行バグリスクが高いという感じ https://t.co/xYGHs1mjnJ
Get a list of mutex?
A program creates a mutex as part of its start-up. I don't know the format of this mutex so I wondered if there is a way to get a list of all non-abandoned mutex, open the program, get a new list and see if I can find the mutex by removing all duplicate entries. Is there a way to get this list?
Hideyuki Tanaka on Twitter: "実際使うときなんて、最初&Tにして、 mutが必要やわ→mutつける オブジェクト間で参照を共有するわ→Rcつける やっぱｽﾚｯﾄﾞ間でも共有するわ→Arcにする 共有しつつ書き込みたいわ→Mutexつける とかそんな感じよ(´･_･`)"
実際使うときなんて、最初&Tにして、 mutが必要やわ→mutつける オブジェクト間で参照を共有するわ→Rcつける やっぱｽﾚｯﾄﾞ間でも共有するわ→Arcにする 共有しつつ書き込みたいわ→Mutexつける とかそんな感じよ(´･_･`)
Mutexはif let ... elseブロックに渡って保持される話 Twitterで次の記事が流れてきて、所見でなにも分からなかったので調べてみました。 記事のおさらい 上記の記事を読めば分かると思いますが、一応簡潔に説明します。 2つのスレッドからcounterにアクセスする際にロックを取得するが、if let { ... } else { ... }を抜けるまで、別スレッドで取得したロックが開放されない if let Some(_) = counter.lock().unwrap().checked_div(i) { // lock scope + // | } else { // | thread::sleep(time::Duration::from_millis(100)); // | } // -----------+
ogiwara on Twitter: "火星探査機がmutexのせいでバグったの、面白すぎるね https://t.co/ZY7N6NXpUC"
火星探査機がmutexのせいでバグったの、面白すぎるね https://t.co/ZY7N6NXpUC
概要 Go言語では、複数のゴルーチン（スレッド）が同時に実行されることがあるため、共有リソースへのアクセス制御が必要です。そのために、mutex（ミューテックス）と呼ばれる排他制御機構が提供されています。mutexを使うことで、複数のゴルーチンから同時にアクセスされた場合に、競合状態（race condition）を避けることができます。 サンプルコード 以下のサンプルコードでは、3つのゴルーチンがそれぞれカウントアップを行います。しかし、共有変数であるcountに複数のゴルーチンから同時にアクセスされるため、競合状態が発生します。そこで、mutexを使ってcountに対するアクセスを排他制御します。 package main import ( "fmt" "sync" ) func main() { var count int var wg sync.WaitGroup var mu s
goroutineによる並行処理で共有リソースにアクセスしなければならないとき、排他制御が必要になります。ここでは、sync.Mutexを利用した排他制御の実装方法を確認します。(mutexは、mutual exclusionの略です。) package main import ( "fmt" "sync" ) type counter struct { v map[string]int } func (c *counter) Inc(wg *sync.WaitGroup) { defer wg.Done() c.v["wakuwaku"]++ } func main() { wg := sync.WaitGroup{} c := counter{v: make(map[string]int)} for i := 0; i < 1000; i++ { wg.Add(1) go c.Inc(
Zephyr入門（排他制御：mutex編） - Qiita
本稿は、できる限り多くの方、特にRTOSの勉強がてら拝見されている方にはぜひ読んでいただきたいと考えます。本稿で扱っているmutexの機構は、RTOSで非常に重要な役割であり、Zephyrに限らず、どのRTOSでも同様の実装がされているためです。 ちなみにLinuxでも優先度継承機能を備えています。 排他制御とは 皆さんご存知だと思いますが、同一のリソースを複数のスレッドが同時にアクセスして、システムに不整合が発生することを防ぐための機能を排他制御と言います。 競合はスレッド間、スレッドと割込み処理、割込み処理間などが考えられます。 これまでに出てきたirq_lock ( )はスレッドと割込みの競合や割込み間の競合を防ぎ、本稿で説明するmutexはスレッド間の競合を防ぎます。 mutexについては下記3つのシステムコールを用意しています。 void k_mutex_init(struct
Redmine をバージョンアップしようとして rake db:migrate したら rake aborted! (uninitialized constant ActiveSupport::Dependencies::Mutex) - 元RX-7乗りの適当な日々
※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/03)です。 ※ 情報が古い可能性もありますので、ご留意ください。 なんとかしたログ。 タイトル通り、Redmine を 1.1.2 へバージョンアップする際、DB のマイグレーションで↓のようなエラーが発生した。 $ RAILS_ENV=test rake db:migrate (in /usr/local/redmine-1.1) rake aborted! uninitialized constant ActiveSupport::Dependencies::Mutex色々と調べていたら、、、↓に辿りついた。 RubyGems 1.3.1 or higher is required (Rails 2.3.5 will fail with RubyGems 1.5.0 and later, stick
#include <iostream> #include "opencv2/opencv.hpp" #include "opencv2/highgui.hpp" #include<thread> #include<time.h> #include<mutex> cv::VideoCapture cap(1); cv::Mat frame; std::mutex mtx; void GetFrameFromCameraFunction() { while (true) { std::lock_guard<std::mutex> lock(mtx); printf("\nRead Thread\n"); cap.read(frame); } } int ShowFrameFromCameraFunction() { while (true) { std::lock_guard<std::mut
mutex は、相互排他ロックです。 このロックを保持できるのは、1 つのスレッドだけです。 mutex は、データまたはその他のリソースを同時アクセスから保護するために ...
mutex のロックは、コストが高い、ということでしたが、アトミックを使ったほうが、今回の単純なケースでは、速い、ということが解りました。 また、_Atomicを利用した場合のほうが、ソースコードも簡単になります。 pthread_mutex_lockを使うと pthread_mutex_unlock の呼び出しも必要になり、コードが汚くなってしまいます。 ヘッダファイル サンプルコードの意味 ２つのスレッドを同時に実行します。 片方の１つのスレッドは、グローバル変数 shared_data をインクリメントし続けます。 もう１つのスレッドは、グローバル変数 shared_data をデクリメントし続けます。 最終的に 0 になることを期待します。 ロックなしのコードは、アトミックに処理できないので、結果は不定です(0かもしれないし、0以外かもしれない)。 pthread_test1_no
1度に1スレッドのみアクセス可にすることで整合性を保つ。 成果物 github 参考 https://doc.rust-jp.rs/book/second-edition/ch16-03-shared-state.html Mutex use std::sync::Mutex; fn main() { let m = Mutex::new(5); { let mut num = m.lock().unwrap(); *num = 6; } println!("m = {:?}", m); } MutexはMutexGuardというスマートポインタの一種を返す MutexGuardのDropでロック解除する 複数スレッド間 use std::sync::Mutex; use std::thread; fn main() { let counter = Mutex::new(0); let m
速ければ速いほど良い。どうもかわしんです。トランザクションを実装中です。 トランザクションの並行処理で S2PL (Strict Two Phase Lock) を Go で実装しようとしているのですが、どうしても昇格可能な Reader Writer Mutex が必要になり、Github にいい実装がなかったので自分で実装しようとしています。 さて、独自の Mutex を実装するにあたり goroutine 同士の待ち合わせは何かを使って実現する必要がありますが、Go には sync.Mutex とチャネルがあります。 どちらとも、ロックしてアンロックするということができます。振る舞いは同じです。 振る舞いが同じとなればどちらが速いかが重要となります。 ということで実験してみました。 実験 環境は以下の通りです。 OS : macOS 10.14.6 Hardware : Macboo
Goのsync.Mutex - Qiita
研究でquic-goを使っていて、sync.Mutexというのが出てきて使い方を調べたのでメモ。 そもそもmutexとは In computer science, a lock or mutex (from mutual exclusion) is a synchronization primitive: a mechanism that enforces limits on access to a resource when there are many threads of execution. A lock is designed to enforce a mutual exclusion concurrency control policy, and with a variety of possible methods there exists multiple unique im
（前段）複数スレッドから１つの変数を編集する Rustでマルチスレッドのプログラムを書く場合 ArcとMutexを組み合わせることで、1つの変数を複数のスレッドから参照・変更することができる // 複数のスレッドでカウントアップできるカウンター変数 // clone してからスレッドにmoveして持ち込む let counter = Arc::new(Mutex::new(0)); // スレッドの中では、ロックしてから使う let mut num = counter.lock().unwrap(); *num += 1; リスト16-15: Arcを使用してMutexをラップし、所有権を複数のスレッド間で共有できるようにする 本題の前に、Arcって何？ Rc<T>: reference counting(参照カウント)の省略形 参照の数が0になったら、その値は片づけられる Arc<T>は
![[Rust] if let と mutex lock の組み合わせでハマった - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ebc1fd6d696118c14863c1bc0d6ab3f6fc2215d5/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCUnVzdCU1RCUyMGlmJTIwbGV0JTIwJUUzJTgxJUE4JTIwbXV0ZXglMjBsb2NrJTIwJUUzJTgxJUFFJUU3JUI1JTg0JUUzJTgxJUJGJUU1JTkwJTg4JUUzJTgyJThGJUUzJTgxJTlCJUUzJTgxJUE3JUUzJTgzJThGJUUzJTgzJTlFJUUzJTgxJUEzJUUzJTgxJTlGJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00NTVjNzRmNzc5NDc5NzgxMDIyYTY0ZGQ5ZmU5YTM0NA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwdDEzODAxMjA2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzImdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1kYTk1NDYxZDlhOGQ2MGMzYTY5OTBiMTVmMTA5MjNkNw%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D5c6eee8c4c1b88f3a2a5268f2f52d6bc)
2024/06/17 追記 利用編とも呼べる続編も書いたのでそちらも読んでみてください。 きっかけ それはGeminiを試そうと、以下の公式サンプルで遊んでいたときのことでした。 使用しているgoogle_generative_aiパッケージの実装であるchat.dartを眺めていると、定義された変数の中に生成AI関連っぽくないやつがいる…なにこれ！？となったというわけです。 final class ChatSession { //こういうのは生成AIの関連っぽい final Future<GenerateContentResponse> Function(Iterable<Content> content, {List<SafetySetting>? safetySettings, GenerationConfig? generationConfig}) _generateContent
前提 排他制御: 同時処理を防ぐ仕組み(参考: https://wa3.i-3-i.info/word11316.html)で、セマフォで実現。 セマフォ: 同時処理可能なプログラム数を管理する仕組み(参考: https://wa3.i-3-i.info/word13357.html) ミューテックス: 0~1しかないセマフォで、デッドロックを防止する仕組みが組みこまれているもの(参考: https://wa3.i-3-i.info/word13360.html)。排他制御で使われる。 ブロッキング・ノンブロッキング: ざっくりとは同期処理・非同期処理のこと。 概要 gem「redis-mutex」 Redisを使ったRubyでのミューテックス。 同期処理・非同期処理ともにサポート。 例えば以下のように使う。 # [引数] # - lock_name: ロック名 def sample_pr
![[Rails]Gem: redis-mutex - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/63e0b3babcfb1f62a9e3950cffa67328d6190515/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCUmFpbHMlNURHZW0lM0ElMjByZWRpcy1tdXRleCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MGFlNDZkY2U4ZDhmYjlmMzdhNmQ4MDU0MTkxZTJlYjg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBXaXN0ZXJpYVdhdmUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWJkNzhjYjcxZjZhOGQyZDI3M2EyYzZkOWFiOWEyOGUy%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd515dd4c8366ba9bd628dcae030f9255)
セッション跨いで名前付き Mutex を使ったときにうまく動かなかった件 (System.Threading.Mutex, Global Mutex, 所有権, prefix "Global\") - いろいろ備忘録日記
概要 セッション跨いでいる場合は？ サンプル (1) ユーザセッション側で起動するやつ (2) タスクスケジューラで起動するやつ 名前に Global\ を付ける 概要 知らなかったので忘れないうちにメモメモ。 プロセスまたいで排他制御したいときに、よく Mutex とか Semaphore とか使いますが このとき Mutex には名前をつけてやります。 var mutex = new Mutex(false, "hogehoge"); こんな風に。よくアプリの二重起動防止とかで使いますね。 dobon.net セッション跨いでいる場合は？ んで、知らなかったのが、この使い方だと、同一セッション内では排他制御できるけど セッション跨いでいる場合は駄目ってことでした。 （まあ、ほぼこんな状況ないと思いますが、、、、あったりするんです現実。。。） つまり、片方をユーザセッションで起動、もう片
前回 GoのSync.mutexを内部実装から理解したい（StarvingMode編） 前回、前回とmutexの挙動を見てきましたが、awoke、mutexWokenは飛ばしたままでした、 今回はawokeの役割についてを解説していきます。 まずmutex.goのLockSlowでspinパートがあり、そこでawokeがあったことを思い出します。 for { // Don't spin in starvation mode, ownership is handed off to waiters // so we won't be able to acquire the mutex anyway. if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) { // Active spinning ma
はじめに 著者はRust初心者です。間違いなどあればご指摘いただければと存じます。 以下のハンズオンをもとに説明する 最後のプロジェクト: マルチスレッドのWebサーバを構築する シングルスレッドサーバーを立てる 手順 tcpListenerを127.0.0.1:7878に設定 listenerでクライアントからのリクエストを処理 handle_connectionでhttpのヘッダーを読み取ってその内容によって処理や表示ページを分ける main(説明しませんので先述のサイトを見ていただければと存じます) use std::io::prelude::*; use std::net::TcpListener; use std::net::TcpStream; use std::time::Duration; use std::fs; use std::thread; fn main() {
ESP32-freeRTOSのtask関連ラッピングクラス2で作成したクリティカルセクションを示すためのSpinlockと同じようなインターフェースを持つものとしてstd::mutexがあるので、これらで動作がどう違うのかを見てみたいと思う。 概要 SpinlockはCritical Sections & Disabling Interruptsをもとに作成されたものでCPUコアの実行権を資源とみなし排他制御を行う機能で、std::mutexはhttps://cpprefjp.github.io/reference/mutex/mutex.htmlに示されているように「共有リソースを排他制御するためのクラス」になる。 std::mutex ソースをたどっていくと最終的にはxSemaphoreCreateMutexを利用したものであることが分かった。 std::mutex packages\
はじめに 本記事は C++11で始めるマルチスレッドプログラミングその1 ～std::thread事始め～ - すいバカ日誌 の続きとなる記事です（何年越しだよ）． 今回は std:;mutex による基本的な排他制御について書きます． 本記事を書いた時点では C++17 がもう策定されていますが，タイトルはC++11のまま行きます． 排他制御について 異なるスレッドが同じリソースを共有するような場面は当然発生します． しかし，異なるスレッドが共有リソースに対して同時にアクセス（すくなくとも1つは変更操作）をした場合，データ競合 (data races) が発生し，未定義動作となってしまうことがあります．ちなみに，data races は C++ の規格としてその定義が書かれているので参照してください．*1 データ競合が問題になる例として，双方向 linked-list (以下単に lis
log4netの起動処理の追っかけは難しかったので、いったん飛ばしておきます。 とりあえず、次のステップのFileAppenderの処理について細かくみていきます・・・ FileAppenderクラスはこんな感じに実装されています！ ということで、上から見ていきます。 ロックモデルについて。 ロックモデルは、FileAppenderを使ってログを出力するときに、出力中のファイルに対して、どのように排他制御を行うかを決める方法のようなものです。 実行環境によって使えるモデルと使えないモデルがありますが、.NET Frameworkを利用するばあいは、３つのモデルを利用することができます。 それぞれは以下の通り。 １）InterProcessLock ファイル名を使った名前のmutexインスタンスを使ってロックを管理。 ２）MinimalLock 出力するときだけファイルをロックする。 複数プ
Goでコードを書いてて、排他制御のためsync.Mutexを使っていた。 テストしてると、ある時点でロック獲得待ちのままずっと止まってしまい「あれ・・・？？？」てなったので覚えてるうちにメモ。 原因：Lock()するメソッドの中でさらにLockするメソッドを呼んでいた たとえば次の構造体Testで変数 value を排他制御したいとする。 そうなると、valueを触るメソッドではすべて sync.Mutex をつかってロックをかけるのだが、次の例ではうっかり Increment() の中で自身の値をログに出そうとして、直接 value を参照せずに、Value()メソッドを呼んでしまった。すでにLock()済みな時点でValue()を呼び出そうとしても、ロック獲得ができないのでずっと待ち続ける。 package main import ( "log" "sync" ) func main(
Linux Kernel: rtnl_mutex を長時間 ロックして刺さった状態を観察する (2) with bpftrace - hibomaの日記
前回の続き hiboma.hatenadiary.jp rtnl_mutex でロックを獲得してクリティカルセクションを実行中のタスクを何らかの方法でトレースしたり、時間を計測したいと思って、あれこれ調べたり、試行錯誤していた 最終的に bpftrace でがちゃがちゃと試すまでを記していく 案 A: CONFIG_LOCK_STAT Kernel の設定で CONFIG_LOCK_STAT を有効にしていると各種ロックの統計を取ることができるようです sites.google.com CONFIG_LOCK_STAT は CONFIG_DEBUG_KERNEL に依存した設定なので、production 環境なワークロード化で導入するのはなかなか難しそうかな? CONFIG_LOCK_STAT の設定を Ubuntu (Vagrant) で確認したけど有効でないな (Ubuntu はデバ
始める前に注意点 GolangのG,P,scheduleについての理解があるとより分かりやすくなるかと思います。 GやPについての解説も書いていきたいと思っていますが、下記に参考になる記事を貼っておきます。 Schedule https://qiita.com/tobi-c/items/41e6c786c858a513f67e https://qiita.com/takc923/items/de68671ea889d8df6904 https://qiita.com/niconegoto/items/3952d3c53d00fccc363b https://dtyler.io/articles/2021/03/28/goroutine_preemption/ G,M,Pについて https://niconegoto.hatenadiary.jp/entry/2017/04/11/09281
このエントリーは #kosen10s Advent Calendar 2017 10日目のエントリーです。前日の担当はさつまで、共分散行列適応進化戦略(CMA-ES)と自然勾配法というエントリーでした。 では本題。 私は研究領域の都合上、マルチスレッドを扱っており、C/C++で自前のmutexまがいなことをしなければならないことが多々ある。 自前でやらなきゃいけないのは、往々にしてpthread_mutexの類で実現できないことがあるからだ。 しかし、一般的には自前で排他/同期制御をすることは重大なバグの温床となってしまう。 とはいえ、pthread_mutexだって人が作ったものだから、理解さえすれば、自前で正しい排他制御をできるはず。 本エントリでは自前の排他制御をどう実現するかというのを念頭において、pthread_mutexがどうして排他制御をできるのか、glibcを覗きながら理解
mutex関連記事 やりたいこと C#のアプリとC++のアプリの2つのアプリから一つのリソース(例えばファイル)に読み書きするときに、同時に読み書きしてしまうといろいろ都合が悪いので、同時にアクセスしないように排他制御をしたい。 やり方 Mutexを使う。基本的には、 別のアプリと同じ名前の名前付きMutexを作る。 そのMutexを所有権を要求(WaitOne)して、 使える状態(シグナル状態)であれば、そのまま自分が所有して、使いたいリソースを使う。 他ですでに所有されている状態(非シグナル状態)であれば、他がmutex開放して使える状態になるまで待つ。 使いたいリソースを使い終わったら、所有していたmutexを開放(Release)する。 という流れでmutexを使う。 C#のサンプルコード 下記が、WPFでmutexを使うサンプルコード。別途C++版も作成して両方からmutexを使
![[C#] Mutexでリソースの排他制御をする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4c3a763f6f45a08f5b5b09d1b8a65e8c1bceca5/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCQyUyMyU1RCUyME11dGV4JUUzJTgxJUE3JUUzJTgzJUFBJUUzJTgyJUJEJUUzJTgzJUJDJUUzJTgyJUI5JUUzJTgxJUFFJUU2JThFJTkyJUU0JUJCJTk2JUU1JTg4JUI2JUU1JUJFJUExJUUzJTgyJTkyJUUzJTgxJTk5JUUzJTgyJThCJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1mYzhiMjgyOTg4Y2FmYzUwM2VjZDJmMjE1NDllODQzYw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0ZXJhMTcwNyZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDBhMWFjOGIxMDAxNzg1YzNmZGE4NTM3NmY3N2FkZDU%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D2771f60142e19b5bfb279287f2760ddc)
前回 GoのSync.mutexを内部実装から理解したい 前回通常モードの動きを見ました。 今回はstarvingModeについていきます。 まずはいつstarvingModeになるかから見ていきましょう。 いつStarvingModeになるか 前回canSpin条件を満たせず、runtime_SemacquireMutexでGが寝てしまったことを思い出しましょう。 今回はGが目覚めたところから話を始めていきます。 goparkunlock(&root.lock, waitReasonSemacquire, traceEvGoBlockSync, 4+skipframes) if s.ticket != 0 || cansemacquire(addr) { break } Gが目覚めると、sema.goの上記の部分に戻ります。 s.ticket!=0という条件は後で解説しますので今は飛ばし
[Ruby]warning: already initialized constant Digest::REQUIRE_MUTEXの解決法 - Qiita
~省略/.rbenv/versions/3.0.2/lib/ruby/3.0.0/digest.rb:6: warning: already initialized constant Digest::REQUIRE_MUTEX 〜省略/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/digest-3.1.0/lib/digest.rb:20: warning: previous definition of REQUIRE_MUTEX was here
![[Ruby]warning: already initialized constant Digest::REQUIRE_MUTEXの解決法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4cf73dbb4236a08f960cf29dead7f5aa546e7123/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTIwJTVCUnVieSU1RHdhcm5pbmclM0ElMjBhbHJlYWR5JTIwaW5pdGlhbGl6ZWQlMjBjb25zdGFudCUyMERpZ2VzdCUzQSUzQVJFUVVJUkVfTVVURVglRTMlODElQUUlRTglQTclQTMlRTYlQjElQkElRTYlQjMlOTUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWMwZGUzOTMyZDliNTQ3OWQ2NmY0MGU0ZmM3NDMxNjVi%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrb25qaWtpY2l0eSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODAzMzc1NDI0YTk5YWQ2N2E3YjExNjQwNDU0ODg1MmE%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D38f7be0f64df3487af36487b2a3f278c)
マルチスレッドプログラミングでスレッド間で共有データにアクセスするときに、mutex(MUTual EXclusion, ミューテックス)を用いて、排他ロックを行うことがあります。プログラムに競合状態を引き起こすようなコードがあると、計算の整合性、データの整合性が失われます。競合状態を避ける目的で、クリティカルリージョンをロックで保護します。pthread では、pthread_mutex_tとpthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock を用いて、ロックをコントロールします。 読み方 mutex みゅーてっくす 競合状態 きょうごうじょうたい MUTual EXclusion みゅーちゃる えくすくるーじょん クリティカルセクション くりてぃかるせくしょん critial section くりてぃかるせくし
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Arc<Mutex<T>>という形はデザインパターン - Rustコトハジメ
Mutexは if let ... else ブロックに渡って保持される話
Go言語のmutex排他処理について - Qiita
Go | sync.Mutexによる排他制御(Lock, Unlock) - わくわくBank
C++でカメラ画像取得をでマルチスレッドやってみる：Mutex版 - Qiita
mutex spin_on_owner cpu - Google 検索
pthread mutex lockとAtomic型修飾子の比較 - C言語入門
Rustのスレッド（Mutex、Arc） - やってみる
Go : Mutex は channel の 4 倍速い - kawasin73のブログ
[Rust] if let と mutex lock の組み合わせでハマった - Qiita
mutex.dart（＝ミューテックス排他制御）がおもしろい
[Rails]Gem: redis-mutex - Qiita
GoのSync.mutexを内部実装から理解したい（awoke編） - Qiita
サーバーの作成のチュートリアルをもとにRustのArc、Mutex、トレイト境界、ライフサイクル境界の説明をしてみる
ESP32-Spinlockとmutexの違いについて検証してみた
C++11で始めるマルチスレッドプログラミング その2 std::mutex 編 - すいバカ日誌
log4net × Lock Model × Mutex - きなこもち.net
sync.Mutexを使って初歩的なミスで詰まった思い出 - castaneaiのブログ
GoのSync.mutexを内部実装から理解したい - Qiita
なぜpthread_mutexは機能するのか？ - Sinji's View
[C#] Mutexでリソースの排他制御をする - Qiita
GoのSync.mutexを内部実装から理解したい（StarvingMode編） - Qiita
pthread mutexで排他ロックする方法 - C言語入門