c – 这种障碍的方法是正确的吗？

发布时间：2020-12-16 03:08:41 所属栏目：百科来源：网络整理

导读：我发现pthread_barrier_wait很慢,所以在我的代码的一个地方,我用我的版本的barrier(my_barrier)替换了pthread_barrier_wait,它使用了一个原子变量.我发现它比pthread_barrier_wait快得多.使用这种方法有什么缺陷？这是对的吗？另外,我不知道为什么它比pthrea

我发现pthread_barrier_wait很慢,所以在我的代码的一个地方,我用我的版本的barrier(my_barrier)替换了pthread_barrier_wait,它使用了一个原子变量.我发现它比pthread_barrier_wait快得多.使用这种方法有什么缺陷？这是对的吗？另外,我不知道为什么它比pthread_barrier_wait更快？任何线索？

编辑

>我主要关心的是具有相同数量的线程作为内核的情况.

atomic<int> thread_count = 0;

void my_barrier()
{     
  thread_count++;

  while( thread_count % NUM_OF_THREADS )
   sched_yield();
}

解决方法

您的屏障实施不起作用,至少不会如果屏障将被使用不止一次.考虑这种情况：

> NUM_OF_THREADS-1个线程正在等待屏障,旋转.
>最后的线程到达并通过障碍物.
>最后一个线程退出障碍,继续处理,完成下一个任务,并重新进入障碍等待.
>只有现在,其他等待线程才能安排,并且不能退出障碍,因为计数器再次递增.僵局.

此外,一个经常被忽视但令人讨厌的问题是处理使用动态分配的障碍是破坏/释放它们.只要你知道没有人会再次等待它,你会希望任何一个线程能够在屏障等待返回后执行摧毁/免费,但是这需要确保所有的服务员已经完成了触摸内存任何服务员醒来之前的屏障物体 – 不是一个容易解决的问题.看到我过去关于实施障碍的问题

How can barriers be destroyable as soon as pthread_barrier_wait returns?

Can a correct fail-safe process-shared barrier be implemented on Linux?

除非你知道你有一个特殊情况,没有一个困难的问题适用,不要试图实现自己的应用程序.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!