3

メソッドのドキュメントに特に明記されていない限り、一般的にget-methodsのスレッドセーフを想定できますか？それとも、特に明記されていない限り、スレッドセーフを想定してはならないというのは逆ですか？どう思いますか？

編集：

クラスを想定する

class InfoClass {
  public:
    void Init();
    int  GetInfo();
    void Free();
};

スレッド化されたコンテキストから、スレッド化された操作が終了した後にInit()1回呼び出す。GetInfo()Free()

4

4 に答える 4

4

not thread-safe特に断りのない限り、その方法は想定すべきだと思います。

thread-safe実際、メソッドがデフォルトであると想定する理由はわかりません。

于 2012-07-25T10:40:46.160 に答える
4

スレッドセーフは常に追加の作業を必要とするため、安全に想定できる唯一のことは反対です。直接サポートがない場合、スレッドセーフはサポートされません。

説明：

get単純な64ビット用のterがあり、long long32ビットアーキテクチャで実行されているとします。コンピューターがその長い64ビット値の後半をフェッチしている間（前半で実行されたばかり）、別のスレッドがその後半を更新し、現在、不整合が発生しているため、スレッドセーフではありません。

編集（質問の編集と一致させるため）：

（補足-あなたがクラスを提示した方法は、すべてのメンバーがプライベートであるため、クラスを使用できなくしています）

ビルド後にクラスの状態を変更するアクセスメソッドがない場合は、スレッドセーフを想定できます。しかし、後であなたの仮定について知らない誰かがsetクラスにterを追加し、ランダムエラーのデバッグ体験で素晴らしい旅をするかもしれないので、それはまだずさんな斜面です;）

于 2012-07-25T10:41:08.697 に答える
2

getメソッドはスレッドセーフである可能性がありますが、必ずしもそうとは限りません。クラスがある場合：

class A {
    int value;

    int getValue() {
        return value;
    }

    void processValue() {
        value += 2;
        value = value*2;
    }
}

上記のコードでは、別のスレッドがの2行目にあり、変数が不整合な状態にあるgetValueときに呼び出される可能性があるため、明らかにスレッドセーフではありません。したがって、ここでのゲッターは再入可能ですが（これもそうではない可能性があります）、それでもスレッドセーフではありません。processValuevalue

他の人がこのスレッドで言及しているように、特に指定されていない限り、スレッドセーフではないと想定してください。

于 2012-07-25T10:42:58.123 に答える
0

setメソッドを呼び出すときにメソッドを使用して変数が更新されている場合get、結果はガベージになります。したがって、特に指定がない限り、スレッドセーフは想定できません。

于 2012-07-25T10:41:55.643 に答える