【问题标题】:Does the static method thread-safe?静态方法是否线程安全?
【发布时间】:2015-08-25 14:14:01
【问题描述】:

我正在阅读这篇stackoverflow 帖子,其中给出了示例代码:

static void modifySharedResource(SomeClass sc)
    {
        //do something
        lock (_lock)
        {
            //where sc is modified
        }
    }

我很好奇,为什么这个静态方法需要锁,这个示例中的静态方法是线程安全的吗?

我也看过这个post,但我没看懂答案。

谁能提供更多关于我的问题的详细信息,谢谢!

【问题讨论】:

  • 看起来像单身人士?
  • 一个方法是否是线程安全的取决于它是否访问共享资源(例如静态变量,..)。与方法是否静态无关
  • 一些其他方法当前可能正在作用于对象sc。在这两个地方使用锁可确保这些操作不会同时发生。
  • @Jonesopolis 通常,此方法的调用者有责任确保在该线程运行时所提供的参数不会在另一个线程中被操作。

标签: c# .net multithreading


【解决方案1】:

一个方法是否是线程安全的取决于它是否访问共享资源(例如静态变量,..)。与方法是否为静态无关。

在您的情况下,不确定修改 sc 是否是线程安全的。这取决于如何创建此参数并将其传递给方法。在大多数情况下,如果传入的参数是共享的,就会出现问题。我们在开发一个函数的时候,要保证不管这个函数怎么用都没有问题。

使用您的lock(我假设_lock 是一个静态变量),如果sc 在另一个线程的其他位置被共享和修改,您仍然不实现线程安全。

使用名为modifySharedResource的方法(参数是shared),我很确定如果在另一个线程的其他地方也修改了参数会出现问题。

一般来说,修改传入参数是一种不好的做法:https://softwareengineering.stackexchange.com/questions/245767/is-it-an-antipattern-modifying-an-incoming-parameter

【讨论】:

    【解决方案2】:

    您对线程安全有误解,关键字lock 标记自己参数的同步块索引中的位(代码中的_lock),另一个lock 不能通过直到其他锁释放_lock 并恢复位

    【讨论】:

      【解决方案3】:

      这里的问题是SomeClass 不是线程安全的。此处的静态方法是线程安全的。

      【讨论】:

      • 我不知道你是如何断定带有 // do stuff 的方法是线程安全的。
      • 正如我所说:the method as you have it here 是线程安全的。不幸的是,对于示例中没有的代码,我无法给出任何建议!所以//do something 可能是也可能不是线程安全的。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-11-08
      • 1970-01-01
      • 1970-01-01
      • 2018-01-17
      • 2016-07-16
      相关资源
      最近更新 更多