18 个解决方案
#1
楼主不妨把定时器当做一个线程,这样你就有俩线程而不是一线程了,两线程各干各的。
#2
#3
设置定时器会启动另外一个线程的,所以不会有问题
#4
从来没见过定时器还会启线程的....
#5
看软件定时器如何管理和操作系统如何调度的.如果是用一个线程来管理定时器调度,则看这个线程和你定义的线程谁的优先级高.如果是在硬件中断里管理定时器调度,则会抢占.
#6
处理器设置断点压入PC 还是????难道没人进来说下呢
#7
我感觉是先中断B,执行A,完成后再回到B继续执行。
好像《组成原理》上有相关东西。
好像《组成原理》上有相关东西。
#8
那是说的中断系统,和定时器有关系么
#9
有关系吗?我怎么感觉没有什么关系呢?!
#10
设置定时器后,Sleep(xxxx).看看定时器函数还会不会被执行.
就知道了.如果定时器开启新线程,B函数还会执行的,否则,B函数不会被执行.
定时器实际上跟线程调度有关系,轮到执行该线程的时候系统会检测有没有对应的定时器有的话就调用.
顶贴和接分是一种美德.
就知道了.如果定时器开启新线程,B函数还会执行的,否则,B函数不会被执行.
定时器实际上跟线程调度有关系,轮到执行该线程的时候系统会检测有没有对应的定时器有的话就调用.
顶贴和接分是一种美德.
#11
把定时器看做另外一个线程
#12
我感觉要么用定时器,要么用线程,不要混用.
刚学C++没几天,不知道对否.
刚学C++没几天,不知道对否.
#13
#14
#15
我也不懂啊,学习学习
#16
原来进来一个MM,不要跑,留下联系方式
#17
有可能会出现混乱。
不仅仅是在常规运行与计时器进程之间会出现竞争问题(与时序相关的过程、函数值变化),而且,该计时器内部也可能引发时序错误:当计时器内部进程执行时间≥计时器出发时间时,计时器运行方式及运行结果将会变得不可知起来,尤其是存在计时器嵌套与多计时器并用场合,这主要原因来自于指令集本身:由于复杂指令系统不可能真正做到均等化分时间片,使得操作指令在处理并发问题时始终处于一种模拟状态,而计时器进程在启动与消亡过程中,通常都依赖操作系统给定信号标签来确定当前运行状态,因此,当计时器内部触发进程因I/O问题产生延时时,在数据回填共同的地址段时,将会发生数据竞争与执行问题,这种BUG在仿真并行系统中无法消弭,通常采用的一种方式为操作序列压栈,这也就是我们平常操作中的假死现象;当然,正确的做法是适当的延调触发时间或设定限定信号检测以屏蔽计时器进入竞争状态。这样,A即便触发高优先级任务对B任务而言,无论暂停与否,都不会造成不确定的操作结果。
不仅仅是在常规运行与计时器进程之间会出现竞争问题(与时序相关的过程、函数值变化),而且,该计时器内部也可能引发时序错误:当计时器内部进程执行时间≥计时器出发时间时,计时器运行方式及运行结果将会变得不可知起来,尤其是存在计时器嵌套与多计时器并用场合,这主要原因来自于指令集本身:由于复杂指令系统不可能真正做到均等化分时间片,使得操作指令在处理并发问题时始终处于一种模拟状态,而计时器进程在启动与消亡过程中,通常都依赖操作系统给定信号标签来确定当前运行状态,因此,当计时器内部触发进程因I/O问题产生延时时,在数据回填共同的地址段时,将会发生数据竞争与执行问题,这种BUG在仿真并行系统中无法消弭,通常采用的一种方式为操作序列压栈,这也就是我们平常操作中的假死现象;当然,正确的做法是适当的延调触发时间或设定限定信号检测以屏蔽计时器进入竞争状态。这样,A即便触发高优先级任务对B任务而言,无论暂停与否,都不会造成不确定的操作结果。
#18
先B中断,然后启动一个线程执行定时器相应函数,然后就返回中断处。。然后就看两个线程谁能抢到cpu执行了。。
#1
楼主不妨把定时器当做一个线程,这样你就有俩线程而不是一线程了,两线程各干各的。
#2
#3
设置定时器会启动另外一个线程的,所以不会有问题
#4
从来没见过定时器还会启线程的....
#5
看软件定时器如何管理和操作系统如何调度的.如果是用一个线程来管理定时器调度,则看这个线程和你定义的线程谁的优先级高.如果是在硬件中断里管理定时器调度,则会抢占.
#6
处理器设置断点压入PC 还是????难道没人进来说下呢
#7
我感觉是先中断B,执行A,完成后再回到B继续执行。
好像《组成原理》上有相关东西。
好像《组成原理》上有相关东西。
#8
那是说的中断系统,和定时器有关系么
#9
有关系吗?我怎么感觉没有什么关系呢?!
#10
设置定时器后,Sleep(xxxx).看看定时器函数还会不会被执行.
就知道了.如果定时器开启新线程,B函数还会执行的,否则,B函数不会被执行.
定时器实际上跟线程调度有关系,轮到执行该线程的时候系统会检测有没有对应的定时器有的话就调用.
顶贴和接分是一种美德.
就知道了.如果定时器开启新线程,B函数还会执行的,否则,B函数不会被执行.
定时器实际上跟线程调度有关系,轮到执行该线程的时候系统会检测有没有对应的定时器有的话就调用.
顶贴和接分是一种美德.
#11
把定时器看做另外一个线程
#12
我感觉要么用定时器,要么用线程,不要混用.
刚学C++没几天,不知道对否.
刚学C++没几天,不知道对否.
#13
#14
#15
我也不懂啊,学习学习
#16
原来进来一个MM,不要跑,留下联系方式
#17
有可能会出现混乱。
不仅仅是在常规运行与计时器进程之间会出现竞争问题(与时序相关的过程、函数值变化),而且,该计时器内部也可能引发时序错误:当计时器内部进程执行时间≥计时器出发时间时,计时器运行方式及运行结果将会变得不可知起来,尤其是存在计时器嵌套与多计时器并用场合,这主要原因来自于指令集本身:由于复杂指令系统不可能真正做到均等化分时间片,使得操作指令在处理并发问题时始终处于一种模拟状态,而计时器进程在启动与消亡过程中,通常都依赖操作系统给定信号标签来确定当前运行状态,因此,当计时器内部触发进程因I/O问题产生延时时,在数据回填共同的地址段时,将会发生数据竞争与执行问题,这种BUG在仿真并行系统中无法消弭,通常采用的一种方式为操作序列压栈,这也就是我们平常操作中的假死现象;当然,正确的做法是适当的延调触发时间或设定限定信号检测以屏蔽计时器进入竞争状态。这样,A即便触发高优先级任务对B任务而言,无论暂停与否,都不会造成不确定的操作结果。
不仅仅是在常规运行与计时器进程之间会出现竞争问题(与时序相关的过程、函数值变化),而且,该计时器内部也可能引发时序错误:当计时器内部进程执行时间≥计时器出发时间时,计时器运行方式及运行结果将会变得不可知起来,尤其是存在计时器嵌套与多计时器并用场合,这主要原因来自于指令集本身:由于复杂指令系统不可能真正做到均等化分时间片,使得操作指令在处理并发问题时始终处于一种模拟状态,而计时器进程在启动与消亡过程中,通常都依赖操作系统给定信号标签来确定当前运行状态,因此,当计时器内部触发进程因I/O问题产生延时时,在数据回填共同的地址段时,将会发生数据竞争与执行问题,这种BUG在仿真并行系统中无法消弭,通常采用的一种方式为操作序列压栈,这也就是我们平常操作中的假死现象;当然,正确的做法是适当的延调触发时间或设定限定信号检测以屏蔽计时器进入竞争状态。这样,A即便触发高优先级任务对B任务而言,无论暂停与否,都不会造成不确定的操作结果。
#18
先B中断,然后启动一个线程执行定时器相应函数,然后就返回中断处。。然后就看两个线程谁能抢到cpu执行了。。