|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Miloserdov 2:5020/400 12 Apr 2005 21:26:24
To : Valentin Nechayev
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
Hello, Valentin!
You wrote to Lev Serebryakov on Fri, 8 Apr 2005 22:59:45 +0000 (UTC):
VN>>> будет лежать. И если мьютексная (неважно, с квадратно-гнездовой
VN>>> сериализацией, как в Linux, или скользящей, как во FreeBSD5) понятна
LS>> Что подразумевается под этими терминами?
VN> Термины мои личные, общепринятых не знаю.
[....]
VN> В отличие от Linux, во FreeBSD5 все прерывания (кроме таймерного, да и
VN> то не сразу по введению SMPng) были сделаны как минимальный обработчик
VN> собственно факта прерывания и далее побудка ядерного процесса,
VN> связанного с этим прерыванием и работающего под шедулером; вместо
VN> IPL'ей и спинлоков были введены семафоры с возможностью сна.
И что получилось? Одно дело когда мутекс охраняет доступ к какой либо
глобальной структуре или другому объекту к которому нельзя обращаться
в параллель и при этом нить держит его `столько сколько нужно` т.е.
схватил обратился освободил. И другое дело когда мутекс хватается
просто так - потому что в прошлой версии тут хватали Giant, при этом
и Giant им тоже нужен для некоторых частей его захват не может производится
когда уже что-то держим... и получаем перлы
mtx_unlock(&lock); mtx_lock(&Giant); somefunc(); mtx_unlock(&Giant);
mtx_lock(&lock);
К тому же где-то описано какие локи нужно брать раньше других если нужно
несколько?
Giant не в счет. Просто складывется впечатление (вполне возможно ошибочное)
что над архитектурой долго не думали.
VN> Это простой вариант, он и будет работать без особого насилия. А теперь
VN> представь себе драйвер UFS написанный в среде где не разрешено никаких
VN> вызовов с возможностью ожидания (даже для того чтобы выделить кусок
VN> памяти!) Hадо выделить память, прочитать блок, записать блок -
VN> заказываешь операцию, цепляешь callback hook на её завершение и в этом
VN> хуке разбираешься что получилось и заказываешь следующие действия.
VN> С одной стороны - масштабирование про процессорам идеальное - каждому
VN> только и дела что выдернуть из очереди очередное сообщение и запустить
VN> обработку. С другой стороны, писать под такую среду - повеситься можно.
А в чем разница-то? функции(макросы) ХХХХ_alloc ХХХХ_read и ХХХХ_write
заказывают операцию, цепляют хук и разбирают/возвращают что получилось.
А тебе задумываться об устройстве не обязательно.
VN> И без локов-то всё равно не деться - на один и тот же раздел две
VN> операции так просто не закажешь на двух процессорах - значит, есть
VN> где-то lock manager который смотрит на состав объектов над которыми
VN> действует операция, и даёт на выполнение только то, что не дерётся с
VN> уже занятыми локами. И чем это будет лучше традиционного для pthreads
VN> или FreeBSD5 подхода "хочешь лок, занято - идёшь спать пока не
VN> освободят, а мы пока с кем-то ещё поработаем"?
Hасколько я понял из анонса ( возможно с тех пор они изменили взгляды )
не будет никаких локов. В твоем примере на конкретный раздел сможет
писать только конкретный тред и этот тред будет привязан жестко к
конкретному
процессору. Так что есть шанс получить систему в которой 1 процессор
загружен
на 100% а остальные idle. Поравьте где неправ.
With best regards, Dmitry Miloserdov. E-mail: dmitry@bis.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
