Question

作为工作项目的一部分，我在C ++中实现了一个读/写锁类。在将我的代码推送到生产之前，我应该在我的类上运行哪种测试以确保它能正常运行。

我显然已经对我的班级进行了一些健全测试（确保一次只能找到一位作家，确保版本和声明正确递增和递减等）。

我正在寻找可以保证班级稳定性和防止边缘情况的测试。似乎测试多线程代码比标准代码更难。

Answer 1

测试多线程代码非常困难，因此您应该在编写多线程应用程序的同事的详细代码审查中补充您的测试。

Answer 2

我想您可以从查看完善代码中包含的测试开始。例如，GNU libc（nptl）的pthreads实现包括读写锁和一些测试。

$ ls nptl/tst-rwlock*
nptl/tst-rwlock1.c
nptl/tst-rwlock10.c
nptl/tst-rwlock11.c
nptl/tst-rwlock12.c
nptl/tst-rwlock13.c
nptl/tst-rwlock14.c
nptl/tst-rwlock2.c
nptl/tst-rwlock3.c
nptl/tst-rwlock4.c
nptl/tst-rwlock5.c
nptl/tst-rwlock6.c
nptl/tst-rwlock7.c
nptl/tst-rwlock8.c
nptl/tst-rwlock9.c

Answer 3

确保在真正拥有多个CPU的机器上进行压力测试。这通常会发现比单个CPU机器上运行的更多多线程问题。

然后在64位，更快的CPU，更多CPU等机器上进行测试

正如@ onebyone.livejournal.com所说，使用具有非连贯内存缓存的机器;但是，根据NUMA article on Wikipedia，可能很难找到。

当然，在尽可能多的不同机器上使用代码不会受到伤害，也是发现问题的好方法。

Answer 4

一般情况下，我会提供指导，以避免实施自己的锁，除非您已经证明现有的稳定实施不能满足您的性能需求。

测试和构建同步原语可能很棘手且不直观。

使用boost :: shared_mutex的指导是非常明智的，如果你在Win32平台上，我会指导你使用Slim Reader Writer Locks，如果可能的话，因为它们强大而且快速。

虽然它对今天的生产产品没有帮助，但在Visual Studio 2010 Beta 1中我们添加了reader_writer class，而不是跨平台将成为VS2010 redist的一部分。

Answer 5

因为你已经实现了读/写锁，所以显然你应该在多线程环境中测试它。当没有写入操作时，不应阻止多个读取线程等测试场景，并且在几个小时内运行数千次读/写操作不应该导致死锁可能是一个良好的开端。

Answer 6

运行两个执行此操作的线程

  long long int j = 0;
  long long int oldJ = 0;
  while (true)
  {
      for (long long int i = 0; i <= 100000; ++i) 
       // try and make it 64 bits to be sure its non-atomics :)
      {       
          oldJ = j;      
          YourRead(j) // read in j
          assert(j == (oldJ + 1));
          SleepSomeRandomPeriod(  );
          YourWrite(i)
          SleepSomeRandomPeriod(  );
      }
  }

Answer 7

经常使用ASSERT / assert测试所有假设并检查前后条件。

Answer 8

如果您可以在工作代码中使用Boost，则应使用实现读/写锁定的shared_mutex类。

即使它不能100％满足您的需求，您也应该使用代码中代码中的想法，如果Boost代码有shared_mutex的测试（我还没有检查过），你应该将它们添加到你的测试中。

Answer 9

IBM有an analysis tool for detecting threading issues in Java。也许C ++有类似的东西？

Answer 10

确保在具有多个CPU内核或至少具有超线程的CPU的计算机上进行测试。多线程线程只会出现许多问题，或者当线程真正在不同CPU上并行运行时会出现更多问题。

读/写锁

10 个答案: