Ядро предоставляет процессу несколько различных служб времени. Эти службы включают таймеры, работающие в реальном режиме, и таймеры, работающие лишь во время выполнения процесса.
Реальное время
Время системы, прошедшее с 1 января 1970 г., по Всеобщему скоординированному времени (Universal Coordinated Time - UTC), известное также как эпоха (Epoch), возвращается системным вызовом gettimeofday. Большинство современных процессоров (включая процессоры PC) поддерживают регистр времени дня с батарейкой. Эти часы продолжают идти, даже когда процессор выключен. Когда система загружается, она использует регистр времени дня процессора для выяснения текущего времени. После этого время системы поддерживается прерываниями от часов. При каждом прерывании система увеличивает значение переменной глобального времени на величину, равную числу микросекунд в тике. Для PC, работающего со 100 тиками в секунду, каждый тик представляет 10 000 микросекунд.
Внешнее представление
Время всегда экспортируется из системы в виде микросекунд, а не тиков часов, для обеспечения независимого от разрешения формата. Внутренне ядро может выбрать любую частоту тиков, которая лучше всего справляется с издержками по обработке прерываний от часов с разрешением таймера. По мере увеличения частоты тиков в секунду разрешение системных таймеров улучшается, но увеличивается время, затрачиваемое на обработку прерываний аппаратных часов. По мере ускорения процессоров частота тиков может возрастать для повышения разрешения без неблагоприятного влияния на приложения пользователей. Системы реального времени часто работают с частотой часов 500 или 1000 тиков в секунду. Все временные метки файловой системы (и других подсистем) содержат смещения UTC от начала эпохи. Преобразование в локальное время, включая учет перехода на летнее время, осуществляется извне системы в библиотеке С.
Большинство действий, связанных с доставкой сигнала потоку, выполняется в контексте этого потока. Поток проверяет свое поле td_siglist на предмет наличия ожидающих сигналов по крайней мере один раз при входе в систему, вызывая cursigQ.
SLEEPING - Поток заблокирован в ожидании события. Если поток находится в состоянии непрерываемого сна, больше ничего не должно предприниматься. В противном случае ядро может предпринять действие - либо непосредственно, либо косвенно, - пробудив поток. Есть два действия, которые можно применить непосредственно. Для сигналов, вызывающих остановку процесса, все потоки в процессе помещаются в состояние STOPPED и родительский процесс уведомляется об изменении состояния посредством отправки ему сигнала SIGCHLD.
Реализация сигналов разделена на две части, первая из которых - отправка сигнала процессу, а вторая - распознавание сигнала и доставка его потоку назначения. Сигналы может отправлять любой процесс или код, который выполняется на уровне прерывания. Доставка сигнала обычно имеет место в контексте получающего потока. Но когда сигнал форсирует остановку процесса, действие может быть проведено для всех потоков, связанных с этим процессом в тот момент, когда сигнал был отправлен.
Сигналы первоначально были спроектированы для моделирования исключительных событий, таких, как попытка пользователя завершить вышедшую из-под контроля программу. Они не предназначались для использования в качестве общего механизма межпроцессного взаимодействия, поэтому не было сделано попытки сделать их надежными. В более ранних системах каждый раз при перехвате сигнала восстанавливалось его действие по умолчанию.
Описание сигналов указывается для каждого процесса. Если процесс не указал действие на сигнал, ему предоставляется действие по умолчанию которое может быть одним из следующих: