如果方法文档中没有另外说明,通常可以假设 get 方法的线程安全吗?还是反过来说,如果没有另外说明,就永远不应该假设线程安全?你怎么看?
编辑:
假设一个班级
class InfoClass {
public:
void Init();
int GetInfo();
void Free();
};
在线程操作结束后从线程上下文调用Init()
一次。GetInfo()
Free()
如果方法文档中没有另外说明,通常可以假设 get 方法的线程安全吗?还是反过来说,如果没有另外说明,就永远不应该假设线程安全?你怎么看?
编辑:
假设一个班级
class InfoClass {
public:
void Init();
int GetInfo();
void Free();
};
在线程操作结束后从线程上下文调用Init()
一次。GetInfo()
Free()
我认为您应该假设该方法是not thread-safe
如果没有另外说明的话。
实际上,我看不出有任何理由假设一种方法是thread-safe
默认的。
线程安全总是需要额外的工作,所以你唯一可以安全地假设是相反的——在没有直接支持的情况下,不支持线程安全。
解释:
假设您有get
一个简单的 64 位 ter,long long
并且在 32 位架构上运行。当计算机正在获取该长 64 位值的后半部分(刚刚完成前半部分)时,另一个线程更新了后半部分,现在您所拥有的是不一致 - 因此它不是线程安全的。
编辑(以匹配问题中的编辑):
(旁注 - 您展示课程的方式使其无法使用,因为所有成员都是私人的)
如果您没有任何访问方法可以在构建类后更改其状态,那么您可以假设线程安全。但这仍然是一个草率的斜坡,因为稍后不了解您的假设的人可能会set
在课程中增加一个 ter 并在随机错误调试体验中拥有一段美妙的旅程;)
get 方法可以是线程安全的,但也不一定。如果有类:
class A {
int value;
int getValue() {
return value;
}
void processValue() {
value += 2;
value = value*2;
}
}
在上面的代码中,getValue
显然不是线程安全的,因为当另一个线程在第二行时可能会调用它processValue
,因此变量value
处于不一致状态。所以,这里的 getter 是可重入的(同样,这可能不是这样),但仍然不是线程安全的。
正如其他人在此线程上提到的,除非指定,否则假定它不是线程安全的。
set
如果在调用方法时使用方法更新变量get
,结果将是垃圾。因此,除非指定,否则不能假定线程安全。