sched_yield的行为

| 我对
sched_yield
函数有几个疑问,因为我发现它没有按我的代码预期的那样工作。很多时候,当我尝试通过调用
sched_yield
屈服它时,即使在存在其他线程的情况下,同一线程也会一次又一次地运行。 另外,如果我有多核,则对于在所有核或仅一个核上运行的线程,将“ 0”屈服。假设我在内核1上运行线程1、2和3,在内核2上运行线程4、5和6,如果从线程2调用了
sched_yield
,它将仅由线程1和3或1,3代替, 4、5和6都可能吗?我之所以这么问,是因为在.Net
Thread.Yield
中,只有在相同内核/处理器上运行的线程才会屈服。     
已邀请:
        http://www.kernel.org/doc/man-pages/online/pages/man2/sched_yield.2.html   sched_yield()使调用线程放弃CPU。线程是      移动到队列的末尾以获取其静态优先级,然后有一个新线程进入      跑。      如果调用线程是那个优先级最高的列表中的唯一线程      时间,它将在调用sched_yield()之后继续运行。 sched_yield不是.Net调用,并且线程/进程模型不同。 Windows / .NET的调度程序与Linux的调度程序不同。 Linux甚至有几个可能的调度程序。 因此,您对sched_yield的期望是错误的。 如果要控制线程的运行方式,可以将每个线程绑定到CPU。然后,线程将仅在绑定的CPU上运行。如果将多个线程绑定到同一CPU,则使用sched_yield可以切换到另一个绑定到当前CPU并准备运行的线程。 如果每个线程要执行大量CPU密集型工作,那么每个CPU使用多个线程也是一个坏主意。 如果要完全控制线程的运行方式,则可以使用RealTime线程。 http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler-SCHED_FIFO和SCHED_RR RT策略。     
        为什么要放弃CPU?好... 我正在修复客户端代码中的错误。基本上,它们有一个共享的结构来保存信息: 托管中有多少硬币-将它们退还 托管中有多少张钞票-退还 上面的代码在过程A中,其余的代码在过程B中。过程B向过程A发送消息,以计算和退还托管资金(这是自动售货机)。无需深入了解为什么以这种方式编写代码,原始代码序列为: (过程B)     发送消息RETURN_ESCROWED_BILLS到进程A     发送消息RETURN_ESCROWED COINS到进程A     归零通用结构 这被执行为: (过程B):     发送消息;     将结构归零; (之后..流程A):     得到消息;     公共结构中的所有字段均为0;     没事做; 糟糕...钱仍然在托管中,但是过程A代码丢失了该知识。真正需要的(除了代码的大规模重组之外)是: (过程B):     发送消息;     产生CPU; (过程A):     确定代管款项并退还;     产生CPU; (可以转到时间片的末尾,不需要特殊方法) (过程B):     归零通用结构; 每当您有IPC消息,并且发送/接收消息的过程紧密耦合时。最好的方法是进行两次握手。但是,在某些情况下(通常是由于设计不佳或不存在而导致的),您必须紧密耦合真正应该是松散耦合的过程。通常,CPU的产量很低,因为您别无选择。多核CPU的增加是痛苦的根源,尤其是从单核移植到多核时。     

要回复问题请先登录注册