Comments 11
Это ядерный мютекс или юзерспейсный? Если юзерспейсный: что если поток завершат принудительно извне в release_mutex() после захвата mutex->ilock? Я как программист ожидаю что все операции над мютексами атомарны.
Вообще, это ядерный код. Пользовательского C-кода вообще не предполагается, для этого будет вирт. машина. Что касается принудительного завершения потока после захвата mutex->ilock, то это невозможно, поскольку захват ilock выключает прерывания, соответственно, поток в этот период монопольно владеет процессором. Другое дело, что поток может быть принудительно завершён или запущен в момент, когда он спит в мьютексе. Ведь описанный мьютекс — это всего лишь надстройка над планировщиком, который ничего о нём не знает. Здесь, наверное, потребуется какая-то защита.
> выключает прерывания, соответственно, поток в этот период монопольно владеет процессором
Наверное, только одним ядром? Или тут нет SMP?
Если нет SMP, то вот тут нужно как раз делать только одну попытку, последующие бессмысленны:
> Зачем делать N попыток захватить mlock, если можно уснуть после первой попытки?
Наверное, только одним ядром? Или тут нет SMP?
Если нет SMP, то вот тут нужно как раз делать только одну попытку, последующие бессмысленны:
> Зачем делать N попыток захватить mlock, если можно уснуть после первой попытки?
перенёс как ответ на коммент выше
Вот такой оффтопичный вопрос: а где автор находит такие потешные игрушки, точнее, их фотографии? :)
Не очень понял идею N попыток захвата:
Время переключения контекста существенно выше одной попытки получить спинлок.Да, но разве освобождение захваченного спинлока не требует переключения на процесс его захвативший?
Смотрите, вообще непрерывные попытки захвата ресурса нужны только тогда, когда у нас есть несколько логических процессоров. В противном случае это пустая трата времени: если ресурс захвачен, то легче просто уступить место другому потоку, ведь всё равно весь оставшийся квант времени ресурс будет занят (его хозяин не планируется).
В случае нескольких процессоров ситуация меняется. Поток, запрашивающий ресурс, знает, что с ним одновременно может исполняться и хозяин ресурса (на другом процессоре). Поэтому его стратегия меняется. Зачем ему сразу уходить в сон? Он может проснуться нескоро (пока переключатся контексты, да и в очереди планирования он будет не первым). Поэтому разумно некоторое время поупорствовать, настойчиво проверяя доступность ресурса. Но не целый отведённый квант (квант может быть большим и вообще, чем дольше ресурс занят, тем выше вероятность, что и останется занятым). Поэтому потом лучше уйти в сон, ожидая что тебя разбудит сам хозяин освободившегося ресурса.
В случае нескольких процессоров ситуация меняется. Поток, запрашивающий ресурс, знает, что с ним одновременно может исполняться и хозяин ресурса (на другом процессоре). Поэтому его стратегия меняется. Зачем ему сразу уходить в сон? Он может проснуться нескоро (пока переключатся контексты, да и в очереди планирования он будет не первым). Поэтому разумно некоторое время поупорствовать, настойчиво проверяя доступность ресурса. Но не целый отведённый квант (квант может быть большим и вообще, чем дольше ресурс занят, тем выше вероятность, что и останется занятым). Поэтому потом лучше уйти в сон, ожидая что тебя разбудит сам хозяин освободившегося ресурса.
Sign up to leave a comment.
Пишу игрушечную ОС (о реализации мьютекса)