TNKernel и удаление объектов синхронизации Опции

[kosyak©]

Копаюсь в недрах TNKernel 2.6. В функциях удаления объектов синхронизации (семафор, мютекс) есть такой код (например функция удаления семафора):

Код

....

   while(!is_queue_empty(&(sem->wait_queue)))
   {
//!!!!!!!!!!!!!!!!!!!!!!!!!!!
      tn_disable_interrupt();

     //--- delete from the sem wait queue

      que = queue_remove_head(&(sem->wait_queue));
      task = get_task_by_tsk_queue(que);
      if(task_wait_complete(task))
      {
         task->task_wait_rc = TERR_DLT;
         tn_enable_interrupt();
         tn_switch_context();
      }
   }

....

Вопрос такой - а что если переключение контекста произойдет в момент отмеченный восклицательными знаками?
Т.е. очередь sem->wait_queue на момент проверки содержала один элемент, попали в цикл, произошло переключение контекста и из нее удалили единственный элемент. Дальше в коде нигде проверок чт из очереди что-то достали я не нашел.

Или я где-то не правильно рассуждаю?

[yuri_t]

Или я где-то не правильно рассуждаю?

Рассуждаете Вы совершенно правильно.

Если queue пустая, то ф-ция queue_remove_head() возвращает 0.

В версиях до 2.6, ф-ции get_task_by_tsk_queue() и task_wait_complete() в этом случае
также вернут 0 и ничего нештатного не случится.

А вот в версии 2.6 ф-ция get_task_by_tsk_queue() была заменена на макрос без проверки
входных параметров(для увеличения скорости работы) и здесь могут появиться проблемы.
В версии 2.7 код этого макроса будет заменен на более надежный.

[kosyak©]

Сейчас я сделал так.

Код

...
   tn_disable_interrupt();
   while(!is_queue_empty(&(sem->wait_queue)))
   {      

     //--- delete from the sem wait queue

      que = queue_remove_head(&(sem->wait_queue));
      task = get_task_by_tsk_queue(que);
      if(task_wait_complete(task))
      {
         task->task_wait_rc = TERR_DLT;
         tn_enable_interrupt();
         tn_switch_context();
         //->
                            tn_disable_interrupt();
      }
   }
.....

Ну и пользуясь случаем ...

Нельзя ли добавить в новую версию объект синхронизации типа POSIX-овского rwlock ?

[yuri_t]

IMHO, здесь будет достаточно что-то типа ( файл tn.h)

Код

#define get_task_by_tsk_queue(que)                  \
       que ? CONTAINING_RECORD(que, TN_TCB, task_queue) : 0

Нельзя ли добавить в новую версию объект синхронизации типа POSIX-овского rwlock ?

POSIX rwlock() будет слишком "тяжелым" для систем типа TNKernel

[kosyak©]

IMHO, здесь будет достаточно что-то типа ( файл tn.h)

Код

#define get_task_by_tsk_queue(que)                  \
       que ? CONTAINING_RECORD(que, TN_TCB, task_queue) : 0

В этом варианте возвращается лишняя проверка

POSIX rwlock() будет слишком "тяжелым" для систем типа TNKernel

Ну может быть какой-нибудь его "облегченный" вариант можно реализовать...
Сейчас у меня, например, есть список у которого куча "читателей" и один "писатель", довольно редко вызываемый. Сейчас все реализовал на мютексах - но получается что читатели "мешают" друг другу.

Решил попробовать сделать свой вариант rwlock'a для TNKernel... но что-то опыта пока не хватает

[yuri_t]

Решил попробовать сделать свой вариант rwlock'a для TNKernel... но что-то опыта пока не хватает

http://www.rfc1149.net/blog/2011/01/07/the...riters-problem/

[kosyak©]

http://www.rfc1149.net/blog/2011/01/07/the...riters-problem/

Спасибо за ссылку. Так я делал...только хотелось бы иметь этот объект с приоритетом "писателя". Т.е. если появился жалающий "писать" все последующие "читатели" ставятся в ожидание.
А как такое реализовать на существующих объектах синхронизации (и без сильного ущерба производительности)?

[yuri_t]

А как такое реализовать на существующих объектах синхронизации (и без сильного ущерба производительности)?

Данный пример кода рабочий но не оптимизирован

Прикрепленные файлы

 rw_with_writer_priority.txt ( 3.79 килобайт ) Кол-во скачиваний: 105