相关疑难解决方法(0)

当我尝试编译这个简单的程序时:

#include<thread>

void f() {
  std::this_thread::sleep_for(std::chrono::seconds(3));
}

int main() {
  std::thread t(f);
  t.join();
}

在Ubuntu 10.04(32位)上使用gcc版本4.4.3:

$ g++ -std=c++0x -pthread a.cpp -o a

我明白了:

error: ‘sleep_for’ is not a member of ‘std::this_thread’

我看着标题'线程'.
sleep_for()受_GLIBCXX_USE_NANOSLEEP保护

#ifdef _GLIBCXX_USE_NANOSLEEP
...
/// sleep_for
template<typename _Rep, typename _Period>
  inline void
  sleep_for(const chrono::duration<_Rep, _Period>& __rtime)
...

为什么_GLIBCXX_USE_NANOSLEEP没有定义？
如何编译这个例子？

2012年9月17日更新(jogojapan):今天我使用GCC 4.7.1遇到了同样的问题.我想知道是否有关于如何避免它的消息,除了定义_GLIBCXX_USE_NANOSLEEP.我尝试过使用-std=gnu11,但无济于事.

GCC 4.4还有一个旧的未解决的错误报告:https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/608145

2012年10月19日更新(jogojapan):现在,Jonathan Wakely已经解决并解决了这个问题,作为这个问题的答案:_GLIBCXX_USE_NANOSLEEP到底是什么？ 这对于自己构建GCC而不是使用现成包的任何人来说尤为重要.

我试图产生当前线程:

的std :: this_thread ::收率();

但不幸的是GCC知道的更好:

'yield'不是'std :: this_thread'的成员

我忘了一些类似于D_GLIBCXX_USE_NANOSLEEP的黑客攻击,或者是什么？

因此,准确的时间是对我很重要,我正在调查这3种类型的C++ 11,即指定的时钟system_clock,steady_clock和high_resolution_clock.我最初关注的是测试不同类型时钟的呼叫开销是否存在差异,以及检查每种类型时钟的分辨率.这是我的示例程序:

#include <chrono>
#include <cstdio>
using namespace std;
using namespace std::chrono;

int main(int argc, char **argv)
{
  size_t N = 1e6;
  if(2 == argc) {
    sscanf(argv[1], "%zu", &N);
  }

#if defined(hrc)
  typedef high_resolution_clock clock;
#warning "High resolution clock"
#elif defined(sc)
  typedef steady_clock clock;
#warning "Steady clock"
#elif defined(sys)
  typedef system_clock clock;
#warning "System clock"
#endif

  const double resolution = double(clock::period::num) / double(clock::period::den);

  printf("clock::period: %lf us.\n", resolution*1e6);
  printf("clock::is_steady: %s\n", clock::is_steady ? "yes" : "no"); …

我正在尝试创建一个简单的池对象,我希望或多或少公平地将对一组共享资源的访问权限分配给任何要求它的线程.在Windows中,我通常会有一个Mutexes数组并执行WaitForMultipleObjects,bWaitAll = FALSE(参见下面的windows_pool_of_n_t).但我希望有一天能够将其移植到其他操作系统,所以我想坚持使用标准.一个资源的deque,大小()!= 0的condition_variable似乎是一个明显的解决方案(参见下面的pool_of_n_t).

但由于我不明白的原因,该代码序列化了线程访问.我并不期望严格公平,但这几乎是最糟糕的情况 - 上次锁定的线程总是在下次获得锁定.这并不是说std​​ :: mutex不符合Windows或多或少的公平调度,因为只使用没有条件变量的互斥锁可以按预期工作,当然只有一个池,当然(参见下面的pool_of_one_t).

有谁能解释一下？有没有解决的办法？

结果:

C:\temp\stdpool>bin\stdpool.exe
pool:pool_of_one_t
thread 0:19826 ms
thread 1:19846 ms
thread 2:19866 ms
thread 3:19886 ms
thread 4:19906 ms
thread 5:19926 ms
thread 6:19946 ms
thread 7:19965 ms
thread 8:19985 ms
thread 9:20004 ms
pool:windows_pool_of_n_t(1)
thread 0:19819 ms
thread 1:19838 ms
thread 2:19858 ms
thread 3:19878 ms
thread 4:19898 ms
thread 5:19918 ms
thread 6:19938 ms
thread 7:19958 ms
thread 8:19978 ms
thread 9:19997 ms
pool:pool_of_n_t(1)
thread 9:3637 ms
thread 0:4538 …