【问题标题】:Can one assume get-method to be thread-safe if not otherwise noted?如果没有另外说明,可以假设 get-method 是线程安全的吗?
【发布时间】:2012-07-23 18:37:57
【问题描述】:

如果方法的文档中没有另外说明,通常可以假设 get 方法的线程安全吗?还是反过来说,如果没有另外说明,就永远不应该假设线程安全?你怎么看?

编辑

假设一个班级

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

调用一次Init(),从线程上下文调用GetInfo(),并在线程操作结束后调用Free()

【问题讨论】:

    标签: c++ thread-safety getmethod


    【解决方案1】:

    线程安全总是需要额外的工作,所以你唯一可以安全地假设是相反的——在没有直接支持的情况下,线程安全不是支持。

    解释:

    假设您有一个简单的 64 位 long longgetter,并且在 32 位架构上运行。当计算机正在获取该长 64 位值的后半部分(刚刚完成前半部分)时,另一个线程更新了后半部分,现在您所拥有的是不一致 - 因此它不是线程安全的。

    编辑(以匹配问题中的编辑):

    (旁注 - 您展示课程的方式使其无法使用,因为所有成员都是私有的)

    如果您没有任何访问方法来更改类在构建后的状态,那么您可以假设线程安全。但这仍然是一个草率的斜坡,因为稍后不了解您的假设的人可能会在课程中添加setter,并在随机错误调试体验中拥有一段美妙的旅程;)

    【讨论】:

    • Uups,更正了 private 的东西。感谢您的回答!
    • 您也可以使用struct 代替class,因为struct 的所有成员默认为public
    【解决方案2】:

    如果没有另外说明,我认为您应该假设该方法是not thread-safe

    实际上,我认为没有任何理由假设方法默认为thread-safe

    【讨论】:

      【解决方案3】:

      get 方法可以是线程安全的,但也不一定。如果有课:

      class A {
          int value;
      
          int getValue() {
              return value;
          }
      
          void processValue() {
              value += 2;
              value = value*2;
          }
      }
      

      在上面的代码中,getValue 显然不是线程安全的,因为它可能会在另一个线程位于processValue 的第二行时被调用,因此变量value 处于不一致的状态。所以,这里的 getter 是可重入的(同样,这可能不是这样),但仍然不是线程安全的。

      正如其他人在此线程中提到的,除非指定,否则假定它不是线程安全的。

      【讨论】:

        【解决方案4】:

        如果在您调用get 方法时使用set 方法更新变量,则结果将是垃圾。因此,除非指定,否则不能假定线程安全。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2020-12-22
          • 1970-01-01
          • 1970-01-01
          • 2010-10-15
          • 1970-01-01
          • 2016-04-22
          • 1970-01-01
          相关资源
          最近更新 更多