Question

I have a thread, which does a function call,

 Thread 1()
 {
 while(1)
 {
 msg =  msgreceive();
condn= msg->condn;
 switch(condn)
 {
 case 0:
 //do sonmething
 break;
 case 1:
  printf("case_1");
  function2()
 break;
  }
}
}

function 2()
{
printf("fn2_Start");
//Do something
function 3();
printf("fn2_end");
}

fucntion3()
{
printf("fn3_Start");
//Do something
printf("fn3_end");
}

Normally i get the printf traces this way,

case_1
fn2_Start 
fn3_Start
fn3_end
fn2_end
case_1
fn2_Start 
fn3_Start
fn3_end
fn2_end
....
....
...

But some times in long run, i get the traces this way

case_1
fn2_tart
fn2_start
fn2 start
case 1
case 1

This is with embedded RTOS device environment.(MQX) Language – C
Is there anyway we can suspect why the sytem can behave this way.This happens when the system is heavily loaded running with about ~93% of memory usage.

Answer 1

If the stdout stream is buffered at the device driver level and outout handled by an interrupt, then when the buffer is full, and if it is designed to simply discard characters rather than perform blocking I/O, then this will result in loss of characters in the output.

If that is the case, then the actual execution is following the normal sequence (and Occam’s Rasor rather suggests that would be the case), but some of the trace output is simply being lost. This hypothesis is supported perhaps by the malformed fn2_tart output.

Using “printf” as a trace method is not non-intrusive. It can both affect and be affected by the way your code runs. Increasing the buffer size may help if the high CPU load periods are relatively short, but if they are permanantly sustained, no ammount of buffering will solve the problem.