回答編集履歴
2
既定で非スレッドセーフを追記
test
CHANGED
@@ -3,8 +3,6 @@
|
|
3
3
|
|
4
4
|
|
5
5
|
.NET Frameworkの文脈ならば、大意としては「あるクラスについて、そのメソッドを異なるスレッドから同時に呼び出しても、仕様通りに動作すると保障される」という感じでしょう。これは、あるクラスのインスタンスに対して、同一メソッドを異なるスレッドから同時に呼び出す/異なるスレッドを異なるスレッドから同時に呼び出す、の両方を含みます。
|
6
|
-
|
7
|
-
|
8
6
|
|
9
7
|
|
10
8
|
|
@@ -15,8 +13,6 @@
|
|
15
13
|
|
16
14
|
|
17
15
|
スレッドセーフは対外的な「仕様」であり、ロックはその「内部実装」と考えたほうがよいです。スレッドセーフを実現するために、内部実装としてロック機構を用いることがよくあります。ただし、ロック機構を用いないスレッドセーフの実現方式もあります。
|
18
|
-
|
19
|
-
|
20
16
|
|
21
17
|
|
22
18
|
|
@@ -38,23 +34,23 @@
|
|
38
34
|
|
39
35
|
|
40
36
|
|
37
|
+
> またスレッドセーフではないメソッドも教えてください。
|
41
38
|
|
42
39
|
|
40
|
+
|
43
|
-
|
41
|
+
基本的にスレッドセーフが明記されていない、内部状態をもつクラスのメソッドは、スレッドセーフではありません。言い換えると、内部実装で特別な考慮をしない限り、大半のメソッドはスレッドセーフではありません。例外として、状態を持たないメソッド=出力結果が入力引数にしか依存しないメソッドは、異なるメソッド呼び出し同士が互いに干渉しようがないため、スレッドセーフなメソッドと考えられます。
|
44
42
|
|
45
43
|
|
46
44
|
|
47
45
|
たとえば、次のメソッド`getUniqueId`はスレッドセーフではありません。一意で重複しないID値を返すことを期待されますが、複数スレッドから同時に呼び出すと、仕様に反した”同じID値”を返す**可能性**があります。
|
48
46
|
|
49
|
-
|
50
|
-
|
51
47
|
```
|
52
48
|
|
53
49
|
class Foo {
|
54
50
|
|
55
|
-
|
51
|
+
private int counter = 0;
|
56
52
|
|
57
|
-
|
53
|
+
public int getUniqueId() {
|
58
54
|
|
59
55
|
return counter++;
|
60
56
|
|
1
誤記修正+α
test
CHANGED
@@ -34,7 +34,7 @@
|
|
34
34
|
|
35
35
|
|
36
36
|
|
37
|
-
スレッドセーフでないメソッドを複数
|
37
|
+
スレッドセーフでないメソッドを複数スレッドから同時に呼び出すと、何が起こるかは保障されません。間違った結果を返すかもしれませんし、何らかの例外をスローしてくるかもしれませんし、偶然に正しく動くかもしれません。(.NET Framework提供クラスだと、丁寧に例外スローするものがいくつかあるようです)
|
38
38
|
|
39
39
|
|
40
40
|
|