Добрый день, нужна помощь в устранении следующей проблемы.

ОС Linux Fedora 2.6

Программа читает файловый дескриптор /dev/serial/chan0, обрабатывает полученные данные
и пишет "ответы" в этот дескриптор. Все это выполняется в бесконечном цикле while (см код).

Программа работает нормально примерно несколько (по разному) тысяч циклов while, после чего ни с того ни с сего
в этом цикле появляются ощутимые задержки длительностью несколько сот микросекунд. Есть подозрение, что
"забивается" стек CPU или еще какие-то системные ресурсы. Программа может работать бесконечно, но из-за
задержек теряется часть данных принимаемых из файлового дескриптора.

CPU LOAD < 1%, память вроде бы не растет, valgrind утечек не находит. На работе других программ задержки
не сказываются. Абсолютно точно известно, что данные извне в файловый дескриптор поступают без задержек.

Программа использует pthreads но ВСЕ они создаются PTHREAD_CREATE_DETACHED.

Причина видимо в THREAD_FUNC, но как дочерняя нить может КАК-ЛИБО влиять на родительский поток ?

Буду благодарен за подсказку где искать проблему.

struct MESSAGE
{
 ssize_t    LEN; // NUMBER OF BYTES IN DATA
 u_char     DATA[1000];

 ~MESSAGE(); // DESTRUCTOR
};

void main()
{
 ssize_t nrx=0; u_char buffer[50]={0};

 int chan = open("/dev/serial/chan0", O_RDWR);

 MESSAGE MSG_BUF;

 if (chan > 0) 
 {
  while (true)
  {
   nrx = read (chan, buffer, 50);

   memcpy (MSG_BUF.DATA, buffer, nrx); MSG_BUF.LEN=nrx;

   START_PROC(&MSG_BUF);  ... ЭТА ПРОЦЕДУРА СОЗДАЕТ ЗАДЕРЖКИ ???!!! ... 
 
  }
 } 
}

void START_PROC(void *arg)
{

 pthread_attr_t attr_PRC; pthread_t tid_PRC; sched_param param_PRC;
 pthread_attr_init(&attr_PRC); param_PRC.__sched_priority=99; 
 pthread_attr_setschedparam  (&attr_PRC, &param_PRC);
 pthread_attr_setschedpolicy (&attr_PRC, SCHED_RR);
 pthread_attr_setdetachstate (&attr_PRC, PTHREAD_CREATE_DETACHED);

 pthread_create (&tid_PRC, &attr_PRC, THREAD_FUNC, arg); 
}

void *THREAD_FUNC(void *arg)
{
 ... PROCESS DATA AND WRITE RESPONSE ...
}

QC wrote:

> Добрый день, нужна помощь в устранении следующей проблемы.
>
> ОС Linux Fedora 2.6
>
> Программа читает файловый дескриптор /dev/serial/chan0, обрабатывает
> полученные данные
> и пишет "ответы" в этот дескриптор. Все это выполняется в бесконечном
> цикле while (см код).
>
> Программа работает нормально примерно несколько (по разному) тысяч
> циклов while, после чего ни с того ни с сего
> в этом цикле появляются ощутимые задержки длительностью несколько сот
> микросекунд. Есть подозрение, что
> "забивается" стек CPU или еще какие-то системные ресурсы. Программа
> может работать бесконечно, но из-за
> задержек теряется часть данных принимаемых из файлового дескриптора.
>
> CPU LOAD < 1%, память вроде бы не растет, valgrind утечек не находит. На
> работе других программ задержки
> не сказываются. Абсолютно точно известно, что данные извне в файловый
> дескриптор поступают без задержек.
>
> Программа использует pthreads но ВСЕ они создаются PTHREAD_CREATE_DETACHED.
>
> Причина видимо в THREAD_FUNC, но как дочерняя нить может КАК-ЛИБО влиять
> на родительский поток ?

> struct MESSAGE
> {
> ssize_t LEN; // NUMBER OF BYTES IN DATA
> u_char DATA[1000];
> 
> ~MESSAGE(); // DESTRUCTOR
> };
> 
> void main()
> {
> ssize_t nrx=0; u_char buffer[50]={0};
> 
> int chan = open("/dev/serial/chan0", O_RDWR);
> 
> MESSAGE MSG_BUF;
> 
> if (chan > 0)
> {
> while (true)
> {
> nrx = read (chan, buffer, 50);
> 
> memcpy (MSG_BUF.DATA, buffer, nrx); MSG_BUF.LEN=nrx;
> 
> START_PROC(&MSG_BUF); ... ЭТА ПРОЦЕДУРА СОЗДАЕТ ЗАДЕРЖКИ ???!!! ...
> 
> }
> }
> }
> 
> void START_PROC(void *arg)
> {
> 
> pthread_attr_t attr_PRC; pthread_t tid_PRC; sched_param param_PRC;
> pthread_attr_init(&attr_PRC); param_PRC.__sched_priority=99;
> pthread_attr_setschedparam (&attr_PRC, &param_PRC);
> pthread_attr_setschedpolicy (&attr_PRC, SCHED_RR);
> pthread_attr_setdetachstate (&attr_PRC, PTHREAD_CREATE_DETACHED);
> 
> pthread_create (&tid_PRC, &attr_PRC, THREAD_FUNC, arg);
> }
> 
> void *THREAD_FUNC(void *arg)
> {
> ... PROCESS DATA AND WRITE RESPONSE ...
> }

Немного необычно ты читаешь данные. read() возвращает не столько, сколько ты
указал (50), а столько сколько было доступно, или блокирует поток. пока не
доступен хотя бы один байт. Если данные читаются по-малу, но часто, не сложно
переусердствовать с созданием потоков на каждый чих.

Твой поток риал-таймовый, что означает, если процессоров на машине меньше чем
риалтаймовыйх потоков, все остальные обычные потоки/процессы будут голодать,
пока риалтаймовые потоки не заблокируются на системном вызове или не заваершат
свою работу. Хотя, скорее, у тебя проблема в коде, который ты не привел.

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

QC wrote:
[]

> struct MESSAGE
> {
> ssize_t LEN; // NUMBER OF BYTES IN DATA
> u_char DATA[1000];
> 
> ~MESSAGE(); // DESTRUCTOR
> };
> 
> void main()
> {
> ssize_t nrx=0; u_char buffer[50]={0};
> 
> int chan = open("/dev/serial/chan0", O_RDWR);
> 
> MESSAGE MSG_BUF;
> 
> if (chan > 0)
> {
> while (true)
> {
> nrx = read (chan, buffer, 50);
> 
> memcpy (MSG_BUF.DATA, buffer, nrx); MSG_BUF.LEN=nrx;
> 
> START_PROC(&MSG_BUF); ... ЭТА ПРОЦЕДУРА СОЗДАЕТ ЗАДЕРЖКИ ???!!! ...
> 
> }
> }
> }

Не приметил, когда писал другое сообщение, что MSG_BUF у тебя на стэке. Данные
могут затираться в тот самый момент, когда они обрабатыватся другим потоком.
Похоже, что поток, который делает read() — SCHED_OTHER, а который обрабатывает —
SCHED_RR — риал-тайм, потому первый поток блокируется, когда другой выполняется,
и не может затереть данные, пока другой поток эти данные обрабатывает.

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

Здравствуйте, MaximE, Вы писали:

ME>Не приметил, когда писал другое сообщение, что MSG_BUF у тебя на стэке. Данные
ME>могут затираться в тот самый момент, когда они обрабатыватся другим потоком.
ME>Похоже, что поток, который делает read() — SCHED_OTHER, а который обрабатывает —
ME>SCHED_RR — риал-тайм, потому первый поток блокируется, когда другой выполняется,
ME>и не может затереть данные, пока другой поток эти данные обрабатывает.


Понял, спасибо, в воскресенье проверю. Странно тем не менее, что первые принятые несколько тысяч пакетов с момента
запуска приложения обрабатываются без задержек, а затем даже одиночный пакет генерит до 600 мс. Что-то копится.
Упрощу и приведу весь код здесь.

Здравствуйте, Аноним, Вы писали:

А>Понял, спасибо, в воскресенье проверю. Странно тем не менее, что первые принятые несколько тысяч пакетов с момента
А>запуска приложения обрабатываются без задержек, а затем даже одиночный пакет генерит до 600 мс. Что-то копится.
А>Упрощу и приведу весь код здесь.

лучше valgrind поставь.

Здравствуйте, MaximE, Вы писали:

ME>Не приметил, когда писал другое сообщение, что MSG_BUF у тебя на стэке. Данные
ME>могут затираться в тот самый момент, когда они обрабатыватся другим потоком.
ME>Похоже, что поток, который делает read() — SCHED_OTHER, а который обрабатывает —
ME>SCHED_RR — риал-тайм, потому первый поток блокируется, когда другой выполняется,
ME>и не может затереть данные, пока другой поток эти данные обрабатывает.

Да, так оно и есть . Получается, что поток SCHED_RR с минимальным приоритетом = 1, имеет
больший приоритет чем поток SCHED_OTHER ?
Спасибо !

QC wrote:

> ME>Не приметил, когда писал другое сообщение, что MSG_BUF у тебя на
> стэке. Данные
> ME>могут затираться в тот самый момент, когда они обрабатыватся другим
> потоком.
> ME>Похоже, что поток, который делает read() — SCHED_OTHER, а который
> обрабатывает —
> ME>SCHED_RR — риал-тайм, потому первый поток блокируется, когда другой
> выполняется,
> ME>и не может затереть данные, пока другой поток эти данные обрабатывает.
>
> Да, так оно и есть . Получается, что поток SCHED_RR с минимальным
> приоритетом = 1, имеет больший приоритет чем поток SCHED_OTHER ?

Верно. SCHED_FIFO и SCHED_RR — риал-таймовые политики, такие потоки всегда
вытесняют любые SCHED_OTHER потоки.

Похоже, что хоть ты и создавал потоки для каждого куска данных, эти потоки
вытесняли поток чтения, т.е. на однопроцессорной машине схема работает совсем
как если бы ты обрабатывал данные в том же самом потоке, в каком читаешь. Может
быть стоит подумать о том, чтобы использовать nonblocking/async io, т.к. у тебя
на практике один поток успевает прочесть и обработать данные?

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk

mr_jek wrote:

> А>Понял, спасибо, в воскресенье проверю. Странно тем не менее, что
> первые принятые несколько тысяч пакетов с момента
> А>запуска приложения обрабатываются без задержек, а затем даже одиночный
> пакет генерит до 600 мс. Что-то копится.
> А>Упрощу и приведу весь код здесь.
>
> лучше valgrind поставь.

valgrind — отличный инструмент, сам пользую.

Единственная проблема — быстродействие. Синтетический cpu valgring работает, по
их утверждению, в 50 раз медленнее твоего железного процессора, поэтому,
например, valgrind'ом невозможно отловить в сервере ошибку, которая
воспроизводится только под большой нагрузкой. В общем случае, им сложно отловить
ошибки, связанные с таймингом, т.к. этот инструмент вносит громадное искажение
по времени, что называют probe effect.

--
Maxim Yegorushkin

No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk