set_current_state 应用
2011-05-12 09:57
225 查看
A: A是一个等待进程等待condition 满足过后退出死循环
A:
while(1)
{
if ( condition ) //条件成立了
goto: OUT
else{
//1:----------------------
set_current_state(TASK_UNINTERRUPTIBLE);
schedule();
set_current_state(TASK_RUNNING);
}
}
OUT:
B进程会唤醒A进程:
B:
wake_up_process(A)
写完之后,虽然测试通过了```但是老感觉有什么问题所下:
在A进程中,首先它判断条件不满足,然后进入到else中如果运行到1:------的时候B进程被抢占进来了`并将A唤醒```
之后A进程被调度回CPU然后沿着1:------以下的部份运行,它设置当前状态,自己调用schedule()错过了这次条件````此后A就会被移出运行队列,永远都睡眠着```
我开始怀疑这段代码,搜索了内核代码,发现内核中很多地方也有相类似的用法无奈之下,向"中文邮件列表"中的众位高手请教,终于发现了问题所在正确的写法应该是这样的:
//1:----------------------//
set_current_state(TASK_UNINTERRUPTIBLE);
if (!condition)
schedule();
set_current_state(TASK_RUNNING);
真是差之毫里,失之千里现把这两段代码分析一下
在第一段代码中如果在标号处被抢占,B调用 wake_up_process(A)将A唤醒,此时A的运行状态会设为TASK_RUNNING如切换到A进程运行时,之后的代码又会将其设为TASK_UNINTERRUPTIBLE
在调用schdule()的时候,会判断进程是自愿放弃CPU还是被抢占出来的,如果是自愿放弃且进程不为运行状态就会将其从运行队列中删除
这样A就永远失去了被调度的机会
在第二种情况中:
1:进程A在set_current_state(TASK_UNINTERRUPTIBLE);之前被抢占,B将其唤配,切换回A后,判断condition条件时,会是一个真值,之后又会被调会TASK_RUNNING这是正常的
2:进程A在set_current_state(TASK_UNINTERRUPTIBLE)之后被抢占,假设抢占地在判断完条件之后这样在B中会将A设为RUNING状态,A切换回来的时候,进入到schdule()后不会被踢出运行队列,只是等待下次调度而已,这也是正常的.
A:
while(1)
{
if ( condition ) //条件成立了
goto: OUT
else{
//1:----------------------
set_current_state(TASK_UNINTERRUPTIBLE);
schedule();
set_current_state(TASK_RUNNING);
}
}
OUT:
B进程会唤醒A进程:
B:
wake_up_process(A)
写完之后,虽然测试通过了```但是老感觉有什么问题所下:
在A进程中,首先它判断条件不满足,然后进入到else中如果运行到1:------的时候B进程被抢占进来了`并将A唤醒```
之后A进程被调度回CPU然后沿着1:------以下的部份运行,它设置当前状态,自己调用schedule()错过了这次条件````此后A就会被移出运行队列,永远都睡眠着```
我开始怀疑这段代码,搜索了内核代码,发现内核中很多地方也有相类似的用法无奈之下,向"中文邮件列表"中的众位高手请教,终于发现了问题所在正确的写法应该是这样的:
//1:----------------------//
set_current_state(TASK_UNINTERRUPTIBLE);
if (!condition)
schedule();
set_current_state(TASK_RUNNING);
真是差之毫里,失之千里现把这两段代码分析一下
在第一段代码中如果在标号处被抢占,B调用 wake_up_process(A)将A唤醒,此时A的运行状态会设为TASK_RUNNING如切换到A进程运行时,之后的代码又会将其设为TASK_UNINTERRUPTIBLE
在调用schdule()的时候,会判断进程是自愿放弃CPU还是被抢占出来的,如果是自愿放弃且进程不为运行状态就会将其从运行队列中删除
这样A就永远失去了被调度的机会
在第二种情况中:
1:进程A在set_current_state(TASK_UNINTERRUPTIBLE);之前被抢占,B将其唤配,切换回A后,判断condition条件时,会是一个真值,之后又会被调会TASK_RUNNING这是正常的
2:进程A在set_current_state(TASK_UNINTERRUPTIBLE)之后被抢占,假设抢占地在判断完条件之后这样在B中会将A设为RUNING状态,A切换回来的时候,进入到schdule()后不会被踢出运行队列,只是等待下次调度而已,这也是正常的.
相关文章推荐
- set_current_state 应用
- set_current_state 应用
- set_current_state 应用
- set_current_state
- 2010-04-20 18:17 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection
- (44)通过继承创建线程对象的例子+getName+setName+currentThread()方法应用介绍
- 解决6410 WINCE6 应用层调用SetSystemPowerState api关机无效的问题
- set_task_state和set_current_state
- 解决6410 WINCE6 应用层调用SetSystemPowerState api关机无效的问题
- Oracle Set命令的应用
- Select()系统调用及文件描述符集fd_set的应用
- Display.getDisplay(MIDlet m)方法与display.setCurrent(Dispalyable disp)方法
- ViewPager.setCurrentItem(int item, boolean smoothScroll);第二个参数的作用
- React setState更新数组中的某个元素Element item
- Qt set current window
- 如何解决Uncaught TypeError: this.setState is not a function
- setDepthStencilState
- 修改ViewPager调用setCurrentItem时,滑屏的速度
- STL——set的应用