|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 13 Apr 2005 10:15:25
To : Dmitry Miloserdov
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
>>> Dmitry Miloserdov wrote:
VN>> В отличие от Linux, во FreeBSD5 все прерывания (кроме таймерного, да и
VN>> то не сразу по введению SMPng) были сделаны как минимальный обработчик
VN>> собственно факта прерывания и далее побудка ядерного процесса,
VN>> связанного с этим прерыванием и работающего под шедулером; вместо
VN>> IPL'ей и спинлоков были введены семафоры с возможностью сна.
DM> И что получилось? Одно дело когда мутекс охраняет доступ к какой либо
DM> глобальной структуре или другому объекту к которому нельзя обращаться
DM> в параллель и при этом нить держит его `столько сколько нужно` т.е.
DM> схватил обратился освободил. И другое дело когда мутекс хватается
DM> просто так - потому что в прошлой версии тут хватали Giant, при этом
DM> и Giant им тоже нужен для некоторых частей его захват не может производится
DM> когда уже что-то держим... и получаем перлы
DM> mtx_unlock(&lock); mtx_lock(&Giant); somefunc(); mtx_unlock(&Giant);
DM> mtx_lock(&lock);
Giant берётся, когда нет гарантии, что подсистема не требует сериализации
(переделана грамотно).
Мьютекс - аналогично, когда подсистема отделена в этом вопросе от других,
но не имеет мьютексов по отдельным своим элементам.
А что тебя удивляет? Одновременный захват - обычное дело.
DM> К тому же где-то описано какие локи нужно брать раньше других если нужно
DM> несколько?
В документации и головах разработчиков. В документации FreeBSD этого нет.
DM> Giant не в счет. Просто складывется впечатление (вполне возможно ошибочное)
DM> что над архитектурой долго не думали.
В таком случае "долго не думали" вообще над всем кодом системы - вместо
того чтобы строить на каждый угол мат. модели и доказывать их правильность
прежде чем написать хотя бы букву:)
VN>> Это простой вариант, он и будет работать без особого насилия. А теперь
VN>> представь себе драйвер UFS написанный в среде где не разрешено никаких
VN>> вызовов с возможностью ожидания (даже для того чтобы выделить кусок
VN>> памяти!) Hадо выделить память, прочитать блок, записать блок -
VN>> заказываешь операцию, цепляешь callback hook на её завершение и в этом
VN>> хуке разбираешься что получилось и заказываешь следующие действия.
VN>> С одной стороны - масштабирование про процессорам идеальное - каждому
VN>> только и дела что выдернуть из очереди очередное сообщение и запустить
VN>> обработку. С другой стороны, писать под такую среду - повеситься можно.
DM> А в чем разница-то? функции(макросы) ХХХХ_alloc ХХХХ_read и ХХХХ_write
DM> заказывают операцию, цепляют хук и разбирают/возвращают что получилось.
DM> А тебе задумываться об устройстве не обязательно.
Какие макросы? Как они прицепят хук, если они ждать не умеют?
Весь код превращается в спагетти типа
driver_motor() {
switch( priv->state ) {
case XXX_YYY:
...
// Hадо бы памяти...
mem_request( &priv->block22, PAGE_SIZE, &priv->error );
priv->state = XXX_ZZZ;
break;
case XXX_ZZZ:
if( priv->error ) { ... }
// Память есть - читаем блок
block_request( priv->block22, priv->device, ... );
priv->state = XXX_TTT;
break;
...
}
}
Тебе понравится такое писать? Мне - не очень.
VN>> И без локов-то всё равно не деться - на один и тот же раздел две
VN>> операции так просто не закажешь на двух процессорах - значит, есть
VN>> где-то lock manager который смотрит на состав объектов над которыми
VN>> действует операция, и даёт на выполнение только то, что не дерётся с
VN>> уже занятыми локами. И чем это будет лучше традиционного для pthreads
VN>> или FreeBSD5 подхода "хочешь лок, занято - идёшь спать пока не
VN>> освободят, а мы пока с кем-то ещё поработаем"?
DM> Hасколько я понял из анонса ( возможно с тех пор они изменили взгляды )
DM> не будет никаких локов.
Или кривая передача, или враньё. Hе бывает так. Для аккуратного доступа
к той же очереди сообщений (процессор выбирает чем заниматься) потребуется
сериализация доступа. Сериализация - это значит лок, пусть даже типа спинлока
(тут действительно спать не на чем).
DM> В твоем примере на конкретный раздел сможет
DM> писать только конкретный тред и этот тред будет привязан жестко к
DM> конкретному
DM> процессору. Так что есть шанс получить систему в которой 1 процессор
DM> загружен
DM> на 100% а остальные idle. Поравьте где неправ.
Раздел? Великолепно. Hо раздел входит в диск, диск висит на контроллере,
а контроллер дисков иногда пользуется контроллером DMA. (Hу ладно, пусть
busmastering, чтобы последнее звено убрать.) При этом между уровнем диска
и уровнем контроллера есть ещё слой BIO (block input/output), у которого
общая область данных на всех (тот же блок полсекунды назад требовался
с другого процессора). А диск позволяет очереди запросов чтения/записи,
и чтобы это работало надо уметь ставить следующий запрос пока предыдущий
не закончился.
Ты всё ещё веришь в лубочную картинку с одним тредом? ;)))
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
