回答編集履歴
6
update
answer
CHANGED
|
@@ -6,7 +6,9 @@
|
|
|
6
6
|
- Mutex(`std::mutex`)は、排他制御を実現する道具（の一つ）です。`std::lock_guard`は、レキシカル・スコープに基づいた自動Mutexロック獲得／解放を行ってくれる補助道具です。
|
|
7
7
|
|
|
8
8
|
排他制御の設計では「どの**データ**を保護するか」をまず考え、**実行時の制御フロー上で**該当データ読み書き操作がロック区間内に正しく含まれるようにします。
|
|
9
|
+
実装観点ではMutexはコード区間を排他的に実行する仕組みですが、概念的には共有資源への**アクセスを排他的に制御**するものです。
|
|
9
10
|
|
|
11
|
+
|
|
10
12
|
----
|
|
11
13
|
|
|
12
14
|
> それぞれの構造体にmutex宣言をし、
|
5
update
answer
CHANGED
|
@@ -1,10 +1,11 @@
|
|
|
1
1
|
質問文をみるに「構造体という型(type)」「関数などソースコード上のスコープ(scope)」「実行時の制御フロー(contorl flow)」で混同されているように思えます。
|
|
2
2
|
|
|
3
3
|
- C++の場合、型情報それ自体は排他制御には何の影響もあたえません。同一構造体のメンバにデータ(`data`)とmutex(`mtx`)を含めるのは、一般にメンテナンス性が良いからそうするというだけです。
|
|
4
|
-
- 排他制御の設計は、制御フロー＝「スレッドがどんな順序で命令を実行するか」に着目して必要があります。これはソースコード上
|
|
4
|
+
- 排他制御の設計は、制御フロー＝「スレッドがどんな順序で命令を実行するか」に着目して必要があります。これはソースコード上で表現されるスコープ（レキシカル・スコープ）とはまた別の話です。
|
|
5
5
|
- C++の場合、排他制御で保護する変数(`data`)の読み書き操作と排他制御を実現するmutex(`mtx`)のロック操作を正しく対応付けるのは、完全にC++プログラマの責任となっています。C++コンパイラは何も助けてくれません。
|
|
6
|
+
- Mutex(`std::mutex`)は、排他制御を実現する道具（の一つ）です。`std::lock_guard`は、レキシカル・スコープに基づいた自動Mutexロック獲得／解放を行ってくれる補助道具です。
|
|
6
7
|
|
|
7
|
-
|
|
8
|
+
排他制御の設計では「どの**データ**を保護するか」をまず考え、**実行時の制御フロー上で**該当データ読み書き操作がロック区間内に正しく含まれるようにします。
|
|
8
9
|
|
|
9
10
|
----
|
|
10
11
|
|
4
update
answer
CHANGED
|
@@ -1,9 +1,11 @@
|
|
|
1
|
-
質問文をみるに「構造体という型(type)」
|
|
1
|
+
質問文をみるに「構造体という型(type)」「関数などソースコード上のスコープ(scope)」「実行時の制御フロー(contorl flow)」で混同されているように思えます。
|
|
2
2
|
|
|
3
3
|
- C++の場合、型情報それ自体は排他制御には何の影響もあたえません。同一構造体のメンバにデータ(`data`)とmutex(`mtx`)を含めるのは、一般にメンテナンス性が良いからそうするというだけです。
|
|
4
|
-
- 排他制御の設計は、制御フロー＝「スレッドがどんな順序で命令を実行するか」に着目して
|
|
4
|
+
- 排他制御の設計は、制御フロー＝「スレッドがどんな順序で命令を実行するか」に着目して必要があります。これはソースコード上に現れるスコープ（レキシカル・スコープ）とはまた別の話です。
|
|
5
|
-
- C++の場合、排他制御で保護する変数(`data`)
|
|
5
|
+
- C++の場合、排他制御で保護する変数(`data`)の読み書き操作と排他制御を実現するmutex(`mtx`)のロック操作を正しく対応付けるのは、完全にC++プログラマの責任となっています。C++コンパイラは何も助けてくれません。
|
|
6
6
|
|
|
7
|
+
Mutex(`std::mutex`)は排他制御を実現する道具（の一つ）です。排他制御の設計では「どの**データ**を保護するか」をまず考え、**実行時の制御フロー上で**該当データ読み書き操作がロック区間内に正しく含まれるようにします。
|
|
8
|
+
|
|
7
9
|
----
|
|
8
10
|
|
|
9
11
|
> それぞれの構造体にmutex宣言をし、
|
3
update
answer
CHANGED
|
@@ -1,3 +1,11 @@
|
|
|
1
|
+
質問文をみるに「構造体という型(type)」と「実行時の制御フロー(contorl flow)」で混同されているように思えます。
|
|
2
|
+
|
|
3
|
+
- C++の場合、型情報それ自体は排他制御には何の影響もあたえません。同一構造体のメンバにデータ(`data`)とmutex(`mtx`)を含めるのは、一般にメンテナンス性が良いからそうするというだけです。
|
|
4
|
+
- 排他制御の設計は、制御フロー＝「スレッドがどんな順序で命令を実行するか」に着目してする必要があります。これはソースコード上のスコープ（レキシカル・スコープ）とはまた別の話です。
|
|
5
|
+
- C++の場合、排他制御で保護する変数(`data`)への読み書きと、対応するmutex(`mtx`)のロック操作を対応付けるのは、完全にC++プログラマの責任となっています。C++コンパイラは何も助けてくれません。
|
|
6
|
+
|
|
7
|
+
----
|
|
8
|
+
|
|
1
9
|
> それぞれの構造体にmutex宣言をし、
|
|
2
10
|
> そのmutexの変数にstd::lock_guard<std::mutex> lock(ここにmutecx変数)をしてあげれば
|
|
3
11
|
> 対象の構造体にロックがかかる認識で合っているでしょうか？
|
|
@@ -8,7 +16,7 @@
|
|
|
8
16
|
両者を近くに配置することでコードの保守性が良くよくなるという効果はありますが、同一構造体のメンバ変数だからといってコンパイル時やプログラム実行時に自動的に面倒を見てくれることは何もありません。
|
|
9
17
|
|
|
10
18
|
ある変数(`data`)への読み書き操作を行うときには、**対応する**mutex(`mtx`)が常にロック済みであることを保証するよう、C++プログラマが明示的にコード記述する必要があります。
|
|
11
|
-
（厳密には全スレッドRead Onlyであればロック不要なケースもありますが、話を単純化するため無視します。）
|
|
19
|
+
（厳密には全スレッドRead Onlyであればロック不要なケースもありますが、話を単純化するため無視します。より詳細は[こちらの記事](https://yohhoy.hatenablog.jp/entry/2013/12/15/204116)もご参考に。）
|
|
12
20
|
|
|
13
21
|
> もし、上記のコードの2つの構造体にいっぺんに排他をかけたい場合、
|
|
14
22
|
> 1つのクラスの中に２つの構造体を入れてmutex宣言をしてあげれば、両構造体に排他かかりますよね？
|
2
update
answer
CHANGED
|
@@ -5,13 +5,13 @@
|
|
|
5
5
|
厳密には「いいえ」。構造体（型）にロックがかかる訳ではありません。
|
|
6
6
|
|
|
7
7
|
ある構造体のメンバになっているmutex(`mtx`)のロック操作と、同構造体のメンバ変数(`data`)操作をセットで扱うのは、プログラマであるあなたの責任になります。
|
|
8
|
-
|
|
8
|
+
両者を近くに配置することでコードの保守性が良くよくなるという効果はありますが、同一構造体のメンバ変数だからといってコンパイル時やプログラム実行時に自動的に面倒を見てくれることは何もありません。
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
ある変数(`data`)への読み書き操作を行うときには、**対応する**mutex(`mtx`)が常にロック済みであることを保証するよう、C++プログラマが明示的にコード記述する必要があります。
|
|
11
11
|
（厳密には全スレッドRead Onlyであればロック不要なケースもありますが、話を単純化するため無視します。）
|
|
12
12
|
|
|
13
13
|
> もし、上記のコードの2つの構造体にいっぺんに排他をかけたい場合、
|
|
14
14
|
> 1つのクラスの中に２つの構造体を入れてmutex宣言をしてあげれば、両構造体に排他かかりますよね？
|
|
15
15
|
|
|
16
|
-
「いいえ」。mutexとデータが同じ構造体
|
|
16
|
+
「いいえ」。mutexとデータが同じ構造体のメンバであることは、本質的には無関係です。
|
|
17
|
-
プログラマであるあなたの責任で、ロック操作とデータアクセスをセットで
|
|
17
|
+
プログラマであるあなたの責任で、ロック操作とデータアクセスを正しいセットで取り扱う必要があります。
|
1
update
answer
CHANGED
|
@@ -4,12 +4,14 @@
|
|
|
4
4
|
|
|
5
5
|
厳密には「いいえ」。構造体（型）にロックがかかる訳ではありません。
|
|
6
6
|
|
|
7
|
-
ある構造体のメンバになっているmutex(`mtx`)のロック操作と、
|
|
7
|
+
ある構造体のメンバになっているmutex(`mtx`)のロック操作と、同構造体のメンバ変数(`data`)操作をセットで扱うのは、プログラマであるあなたの責任になります。
|
|
8
|
+
セットで扱うためにコードの保守性がよくなるという効果はありますが、同一構造体のメンバ変数だからといってコンパイル時やプログラム実行時に自動的に面倒を見てくれることは何もありません。
|
|
9
|
+
|
|
8
|
-
メンバ変数(`data`)への読み書き操作を行うときには、常にmutex(`mtx`)のロック済みであることを保証したコードを
|
|
10
|
+
メンバ変数(`data`)への読み書き操作を行うときには、常にmutex(`mtx`)のロック済みであることを保証したコードをC++プログラマが明示的に記述する必要があります。
|
|
9
11
|
（厳密には全スレッドRead Onlyであればロック不要なケースもありますが、話を単純化するため無視します。）
|
|
10
12
|
|
|
11
13
|
> もし、上記のコードの2つの構造体にいっぺんに排他をかけたい場合、
|
|
12
14
|
> 1つのクラスの中に２つの構造体を入れてmutex宣言をしてあげれば、両構造体に排他かかりますよね？
|
|
13
15
|
|
|
14
|
-
「いいえ」。構造体に含まれるか否か
|
|
16
|
+
「いいえ」。mutexとデータが同じ構造体に含まれるか否かは、何ら関係がありません。
|
|
15
|
-
プログラマであるあなたの責任で、ロック操作とデータアクセスをセット
|
|
17
|
+
プログラマであるあなたの責任で、ロック操作とデータアクセスをセットで正しく扱う必要があります。
|