You neglect to mention the version of the OS, but yes, undelivered pulses
were an issue pre 6.4.0

Fortunately this has been fixed in 6.4.0 - however they are still and
issue since they are a kernel memory leak.  Your design should do everything
it can to avoid having a large buildup of queued pulses.

Regards,

Colin

mario sangalli wrote:
> Hi, I've a problem with cyclic timer:
> In an application running on a Pc-like QNX6.2, x86 system, 100us
> system clock, one process create a 150ms cyclic timer (with a 
> priority of 30).
> In this application (not under our control) the client thread stops 
> to receive the timer pulses, so they will be enqueued but not 
> delivered to any one.
> Another process has a 3ms cyclic timer, with a priority of 190.
> After 5/7 days, we observe a delay in the service of one of the
> the 3ms timer thread pulses: this delay has the same period of 
> the 150ms cyclic timer and increase every day more and more...
> after 10 day it is greater than 1ms, so we have a latency of
> this time in the high priority thread, that is not acceptable.
> The question is: may the pulses generated by timer and not
> delivered be the cause this delay ? Apperently yes...
> Just to test, I've write a program that create a cyclic timer
> (1ms, priority 30) and do not make any MsgReceive, so pulses are 
> not delivered to anyone.... And just after a few minutes the
> high priority process will hung-up because its timeline 
> is out of boudary. After the kill of test application, all
> works fine again...
> It's not clear why a undelivered pulse may overload the system
> in such mode... 
> It seems that pulses are buffered unlimited or untill memory
> will be exausted.
> It is possibile to limits the max number of pulses that can be 
> buffered ?
> Thank You all
> Mario
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post21044
> 

-- 
cburgess@qnx.com