Отправляет email-рассылки с помощью сервиса Sendsay

Профессиональное программирование

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Мастерская программиста" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Декабрь 2002   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Ведущий

Статистика

13.914 подписчиков
-22 за неделю
←   Все выпуски   →

Професиональное программирование


Информационный Канал Subscribe.Ru 
Приветствуем вас!
Доброго времени суток.

Отдельное спасибо всем, кто заходил на наш сайт после предыдущей рассылки. Мы
можем теперь точно знать,
что наша рассылка по прежнему читаема и вам интересна.
В связи с этим мы решили расширить нашу тематику.
Сегодня, предворяя возобновление выхода продолжений рассылок прошлого цикла,
мы открываем еще одну тему.
Тема была анонсирована в описании рассылки.

Хотим сообщить вам, что на нашем сайте http://comp-u.wp-club.net/ открывается
новая рубрика - "Начинающим", где всем желающим будет предложено изучит C C++
в приложении к сегодняшнему дню.
Мы планируем построить обучения на тематических уроках, с помощью которых человек
- закончивший такой курс сможет сразу писать
небольшие програмные продукты.

А сейчас рассылка!


Программирование Real-Time

Краткое вступление в тему Real-Time.

Начнем-ка мы рассматривать полную камушками тему Real-Time программирования.

Давайте для начала опишем то, что я понимаю под, такого рода, программным обеспечением.


-1-

Под это определение можно подвести любую ОС - умеющую работать с процессами и
потоками в режиме разделения ресурсов и времени процессора. В том числе и Windows.
Ведь реально события происходят: сетевые сообщения, нажатия кнопок пользователем
и т.д. и т.п.

Сказать так все же было бы не верно.

Под системами реального времени (РВ в дальнейшем) понимают систему отвечающую
за управление каким-либо реальным процессом. ОС общего назначения, особенно многопользовательские,
такие как UNIX/Windows, ориентированы на оптимальное распределение ресурсов компьютера
между пользователями и задачами (системы разделения времени), В ОС РВ подобная
задача отходит на второй план - все отступает перед главной задачей - успеть
среагировать на события, происходящие на объекте.
Это собственно и есть главная задача ОСРВ.

-2-

В отличии от ОС - есть программы, которые вынуждены быть программами РВ внутри
не РВ операционных систем. К таковым в принципе относятся программы серверов
(Apache), программы сетевых протоколов, типа различных ускорителей интернета
и т.д.

Внутри Embeded system эти задачи становятся особенно актуальными, когда мы говорим
о Wireless коммуникациях.
Системам связи приходится постоянно следить за наличием сигнала, приходу вызовов
от абонента, и т.д.
Давайте рассмотрим несколько аспектов работы таких программ.

- Ждущий режим.

Для огромного числа программ РВ - существуют понятия потоков и процессов. Без
понимания, чем они отличаются - дальше нам говорить нечего, поэтому давайте разберемся.
Процесс - самостоятельная единица ОС - имеющая доступ к собственной памяти из
системных ресурсов, системы сообщений, собственный Instance, т.е. системный идентификатор.

Поток - процесс, имеющий ограничения - он не имеет собственного самостоятельного
ID и обязательно должен быть связан с родительским процессом.
Для организации одновременной работы, как с клиентской частью, так и с постоянным,
но нерегулярным притоком внешних событий, нам необходимо организовать, как минимум,
один поток - отвечающий за работу с клиентом и второй с внешним источником информации,
которым мы управляем.
В этом случае у нас сразу же возникает первый подводный камень.
Если в ждущем от управляемого объекта потоке, поставить обычный напрашивающийся
цикл – типа
do{
}while(!Exit)
мы окажемся в ситуации съедания 90% процессорного времени этим самым потоком.

Чтобы избежать такую ситуацию мы обязаны использовать не просто цикл, а цикл
с задержкой на время, пока сигнала нет. В каждой ОС - для внешних коммуникаций
существует API, отвечающий за ожидание входящих событий.
В WinCE , системе рекламирующейся Майкрософтом как РВ, существует функция WaitCommEvent
для ожидания события на COM порте. Правда она же есть и в обычном Windows но
не в этом дело.
Поток, который занимается ожиданием сигнала, висит на ожидании события, причем
не всегда это приход каких-либо данных, а иногда и командное событие ждет, не
занимая процессорное время.
В случае если событий несколько, они организуются в систему флагов, которые после
выхода из ожидания необходимо оценивать. В системе Nucleus мы имеем такую же
систему API.
Однако во всем этом мы увидим еще один подводный камушек. Выход из такого цикла
невозможен, ибо ожидание внешних событий блокирует поток, если вдруг внешний
управляемый модуль ничего не шлет, по причине поломки. В этом случае мы программно
выйти можем только одним способом, поставить предварительно событие выхода, которое
будет ждать следящий поток, наравне с событиями внешними. В этом случае если
выясняется что система сломана - возможен легальный выход их программы и закрытие
потока внутренними программными средствами корректно, посылкой события выхода.

-3-

Оставим на время тему организации ожидания и вспомним, что кроме этого протоки
должны обмениваться информацией между собой. Однако это не возможно организовать,
так же как и в обычном однопоточном варианте, где в каждый момент времени, только
одна область памяти подвергается чтению или изменению.
Если мы используем общую переменную типа int, для передачи номера сигнала от
ждущего процесса к ответственному за обработку, то в нашем случае мы обязаны
соблюсти "приличия".
Например: ждущий поток заполнил переменную номером задания. Однако в процессе
выполнения этого действия второй поток по приказу пользователя считывает эту
переменную. В этом случае мы можем считать первые два байта нового значения,
а вторые старого, т.к. на деле все равно не возможно точно знать, свободна ли
переменная или нет.
Для того, что бы избежать такой ошибки, мы обязаны предусмотреть защиту общей
памяти от несанкционированного доступа в момент операций чтения/записи.
Когда первый поток обращается к одному из общих мест в памяти задачи, то он должен
проверить имеет ли он право на операцию. Если ответ да, то происходит захват
ресурса, блокировка, затем процедура изменения содержимого и деблокировка, освобождение
ресурса. Если во время блокировки, еще один поток попытается обратиться к этому
же месту памяти, то он наткнется на блок, и будет ждать, пока первый не освободит
ему ресурс.

Заключение.

В качестве домашнего задания - предлагаю вам сделать небольшой пример не на бумаге,
а в голове.
Что произойдет, если при чтении блокированного куска, первый поток будет заблокирован
ожиданием освобождения доступа к памяти, а второй в процессе работы с данными,
зависнет? И как такую ситуацию обойти?
Я специально в тексте опустил эту деталь.
Продолжение следует
http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное