Приоритеты потока.

Thread_Priority_Idle.

Thread_Priority_Lowest.

Thread_Priority_Below_Normal.

Thread_Priority_Normal.

Thread_Priority_Above_Normal.

Приоритет устанавливается в 1 несмотря на класс приоритета родительского потока. Приоритет потока на 2 меньше чем приоритет родительского процесса.

Thread_Priority_Below_Normal приоритет потока на 1 меньше приоритета родительского процесса.

Thread_Priority_Normal приоритет потока равен приоритету процесса.

Thread_Priority_Above_Normal приоритет потока на единицу больше чем приоритет род процесса.

Соотношения значений приоритета процесса и потока при расчете базвого приоритета(не динамически изменяющийся) приведено в таблице: см распечатку.

Системы реального времени.

Главными критериями здесь являются завершение задачи в установленный период. Предотвращение потери данных, предотвращение деградации качество обслуживание за счет накопление в системе ошибок. Диспетчеризация для систем реального времени заключается в:

1. Эффективность поддержки многозадачности (для таких систем подходит только вытесняющая многозадачность).

2. Предотвращение блокировок.

3. Эффективная обработка прерываний(основанная на частом переопределении приоритетов и частом перерасчете динамической составляющей).

Например QNX применяется диспетчерезация FIFO.

Синхронизация процесса.

Решение проблемы множественного взаимодействия-задача первостепенной важности при проектировании информационной системы.

Задача некорректно ведущая себя по отношению к другим способна остановить выполнение в том числе ядра системы, т.е заблокировать ее. Данная проблема стоит особенно остро при проектировании СУБД. Встречаются следующие требования к построению СУБД:

1. Гарантированное поддержание базы.

Главным определение является определением транзакции. Транзакция это логическая единица выполняемой работы требующая обязательного завершения перед переходом к следующей операции главным свойством транзакции является ее атомарность. Есть две главных задачи иллюстрирующие проблемы синхронизации СУБД, первая называется проблемой потерянного обновления. Предположим что одновременно выполняется две операции, первая операция снятия денег со счета в количестве 100руб Т1 и операция занесения денег на тот же расчетный счет Т2 +1000руб, перед началом работы на расчетном счету находится так же 1000руб, оператор начинает операцию снятия денег, перед этим считывает состояние счета (1000руб) и в этот момент отрабатывается операция занесения денег на счет, если все отрабатывается верно на счету должно остаться 1900руб, но в этот момент завершается первая операция которая заносит на счет модифицированная ее значение суммы. Решением в данном случае является обеспечение атомарности каждой из транзакций, проблема зависимости от незафиксированных результатов, если выполнение начнется с операции Т2 а в процессе работы пользователь решит отменить эту операцию, но при этом если операция Т1 успела использоть незавершенные транзакции по Т2 то в этом случае она перезапишет содержимое счета.