多线程代码使Rhino Mocks导致死锁

Question

我们目前在单元测试期间遇到一些问题。我们的类使用 Rhino Mocks 对 Mocked 对象进行多线程一些函数调用。下面是一个简化到最小的示例：

public class Bar
{
    private readonly List<IFoo> _fooList;

    public Bar(List<IFoo> fooList)
    {
        _fooList = fooList;
    }

    public void Start()
    {
        var allTasks = new List<Task>();
        foreach (var foo in _fooList)
            allTasks.Add(Task.Factory.StartNew(() => foo.DoSomething()));

        Task.WaitAll(allTasks.ToArray());
    }
}

接口 IFoo 定义为：

public interface IFoo
{
    void DoSomething();
    event EventHandler myEvent;
}

为了重现死锁，我们的单元测试执行以下操作： 1. 创建一些 IFoo Mocks 2. 当 DoSomething() 被调用时引发 myEvent。

[TestMethod]
    public void Foo_RaiseBar()
    {
        var fooList = GenerateFooList(50);

        var target = new Bar(fooList);
        target.Start();
    }

    private List<IFoo> GenerateFooList(int max)
    {
        var mocks = new MockRepository();
        var fooList = new List<IFoo>();

        for (int i = 0; i < max; i++)
            fooList.Add(GenerateFoo(mocks));

        mocks.ReplayAll();
        return fooList;
    }

    private IFoo GenerateFoo(MockRepository mocks)
    {
        var foo = mocks.StrictMock<IFoo>();

        foo.myEvent += null;
        var eventRaiser = LastCall.On(foo).IgnoreArguments().GetEventRaiser();

        foo.DoSomething();
        LastCall.On(foo).WhenCalled(i => eventRaiser.Raise(foo, EventArgs.Empty));

        return foo;
    }

生成的 Foo 越多，死锁发生的频率就越高。如果测试不会阻塞，请运行几次，它就会阻塞。 停止调试测试运行显示，所有任务仍处于 TaskStatus.Running 状态，并且当前工作线程正在中断

[睡眠、等待或加入]
Rhino.Mocks.DLL！Rhino.Mocks.Impl.RhinoInterceptor.Intercept(Castle.Core.Interceptor.IInitation 调用）+ 0x3d 字节

最让我们困惑的是，Intercept(...) 方法的签名被定义为 Synchronized - 但有几个线程位于此处。我读过几篇关于 Rhino Mocks 和 Multithreaded 的帖子，但没有发现警告（预期设置记录）或限制。

 [MethodImpl(MethodImplOptions.Synchronized)]
    public void Intercept(IInvocation invocation)

我们在设置 Mockobject 或在多线程环境中使用它们时是否做了完全错误的事情？欢迎任何帮助或提示！

Answer 1

这是代码中的竞争条件，而不是 RhinoMocks 中的错误。当您在 Start() 方法中设置 allTask​​s 任务列表时，就会出现问题：

public void Start() 
{ 
    var allTasks = new List<Task>(); 
    foreach (var foo in _fooList) 
        // the next line has a bug
        allTasks.Add(Task.Factory.StartNew(() => foo.DoSomething())); 

    Task.WaitAll(allTasks.ToArray()); 
} 

您需要将 foo 实例显式传递到任务中。该任务将在不同的线程上执行，并且 foreach 循环很可能会在任务开始之前替换 foo 的值。

这意味着每个 foo.DoSomething() 有时不会被调用，有时会被调用多次。因此，一些任务将无限期地阻塞，因为 RhinoMocks 无法处理来自不同线程的同一实例上的事件的重叠引发，从而陷入死锁。

将 Start 方法中的这一行替换

allTasks.Add(Task.Factory.StartNew(() => foo.DoSomething())); 

为：

allTasks.Add(Task.Factory.StartNew(f => ((IFoo)f).DoSomething(), foo));

这是一个很微妙且很容易被忽视的经典错误。它有时被称为“访问修改的闭包”。

PS：

根据这篇文章的评论，我使用 Moq 重写了这个测试。在这种情况下，它不会阻塞 - 但请注意，除非按照描述修复原始错误，否则在给定实例上创建的期望可能无法得到满足。使用Moq的GenerateFoo()看起来像这样：

private List<IFoo> GenerateFooList(int max)
{
    var fooList = new List<IFoo>();

    for (int i = 0; i < max; i++)
        fooList.Add(GenerateFoo());

    return fooList;
}

private IFoo GenerateFoo()
{
    var foo = new Mock<IFoo>();
    foo.Setup(f => f.DoSomething()).Raises(f => f.myEvent += null, EventArgs.Empty);
    return foo.Object;
}

它比RhinoMocks更优雅——并且显然更能容忍多个线程同时在同一实例上引发事件。尽管我不认为这是一个常见的要求 - 就我个人而言，我并不经常发现可以假设事件的订阅者是线程安全的场景。

Answer 2

Maggie，从示例中对我来说并不明显，但如果您有 Visual Studio Ultimate，可能会对您有所帮助...一旦出现死锁，请打破所有进入调试器，然后转到“调试”菜单并选择：

“调试”->“调试”。窗口 ->并行堆栈

Visual Studio 构建了一个漂亮的图表，显示所有正在运行的线程的状态。从那里您通常会得到一些关于哪些锁存在争用的提示。