Пишу игрушечную ОС (о реализации мьютекса)

[gribozavr]

Это ядерный мютекс или юзерспейсный? Если юзерспейсный: что если поток завершат принудительно извне в release_mutex() после захвата mutex->ilock? Я как программист ожидаю что все операции над мютексами атомарны.

[ababo]

Вообще, это ядерный код. Пользовательского C-кода вообще не предполагается, для этого будет вирт. машина. Что касается принудительного завершения потока после захвата mutex->ilock, то это невозможно, поскольку захват ilock выключает прерывания, соответственно, поток в этот период монопольно владеет процессором. Другое дело, что поток может быть принудительно завершён или запущен в момент, когда он спит в мьютексе. Ведь описанный мьютекс — это всего лишь надстройка над планировщиком, который ничего о нём не знает. Здесь, наверное, потребуется какая-то защита.

[gribozavr]

> выключает прерывания, соответственно, поток в этот период монопольно владеет процессором

Наверное, только одним ядром? Или тут нет SMP?

Если нет SMP, то вот тут нужно как раз делать только одну попытку, последующие бессмысленны:
> Зачем делать N попыток захватить mlock, если можно уснуть после первой попытки?

[ababo]

Я имел в виду логический процессор.

[ababo]

Без SMP спинлок вообще был бы не нужен.

[ababo]

перенёс как ответ на коммент выше

[andrewsh]

Вот такой оффтопичный вопрос: а где автор находит такие потешные игрушки, точнее, их фотографии? :)

[ababo]

Google

[boolivar]

Не очень понял идею N попыток захвата:

Время переключения контекста существенно выше одной попытки получить спинлок.

Да, но разве освобождение захваченного спинлока не требует переключения на процесс его захвативший?

[ababo]

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

В случае нескольких процессоров ситуация меняется. Поток, запрашивающий ресурс, знает, что с ним одновременно может исполняться и хозяин ресурса (на другом процессоре). Поэтому его стратегия меняется. Зачем ему сразу уходить в сон? Он может проснуться нескоро (пока переключатся контексты, да и в очереди планирования он будет не первым). Поэтому разумно некоторое время поупорствовать, настойчиво проверяя доступность ресурса. Но не целый отведённый квант (квант может быть большим и вообще, чем дольше ресурс занят, тем выше вероятность, что и останется занятым). Поэтому потом лучше уйти в сон, ожидая что тебя разбудит сам хозяин освободившегося ресурса.

[boolivar]

Да, несколько процессоров я не учел, спасибо.