Трассировки для вызова функции в одном потоке, похоже, не в том порядке, который ожидается - PullRequest
3 голосов
/ 20 февраля 2012

У меня есть поток, который выполняет вызов функции,

 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");
}

Обычно я получаю следы печати таким образом,

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

Но иногда, в конце концов, я получаю следы таким образом

case_1
fn2_tart
fn2_start
fn2 start
case 1
case 1

Это со встроенной средой устройства RTOS. (MQX) Язык - C В любом случае можно ли заподозрить, почему система так себя ведет. Это происходит, когда система сильно загружена и работает с ~ 93% использования памяти.

1 Ответ

2 голосов
/ 25 февраля 2012

Если поток stdout буферизуется на уровне драйвера устройства и выводится обработкой прерывания, то тогда, когда буфер заполнен, и если он предназначен для простого отбрасывания символов, а не для блокирования ввода-вывода, то это приведет к потере символов в выводе.

Если это так, то фактическое выполнение следует нормальной последовательности (и Rasor Оккама скорее предполагает, что это так), но некоторые выходные данные трассировки просто теряются.Эта гипотеза поддерживается, возможно, искаженным выводом fn2_tart.

Использование "printf" в качестве метода трассировки не является неинтрузивным .Это может как влиять, так и зависеть от того, как работает код.Увеличение размера буфера может помочь, если периоды высокой загрузки ЦП относительно короткие, но если они постоянно поддерживаются, никакое количество буферизации не решит проблему.

...