|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Miloserdov 2:5020/400 13 Apr 2005 20:05:40
To : Valentin Nechayev
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
Hello, Valentin!
You wrote to me on Wed, 13 Apr 2005 06:15:25 +0000 (UTC):
DM>> производится когда уже что-то держим... и получаем
DM>> перлы mtx_unlock(&lock); mtx_lock(&Giant); somefunc();
DM>> mtx_unlock(&Giant); mtx_lock(&lock);
VN> Giant берётся, когда нет гарантии, что подсистема не требует
VN> сериализации (переделана грамотно).
VN> Мьютекс - аналогично, когда подсистема отделена в этом вопросе от
VN> других, но не имеет мьютексов по отдельным своим элементам.
VN> А что тебя удивляет? Одновременный захват - обычное дело.
Это не одновременный захват это освобождение мутекса чтобы можно
было взять giant.
DM>> К тому же где-то описано какие локи нужно брать раньше других если
DM>> нужно несколько?
VN> В документации и головах разработчиков. В документации FreeBSD этого
VN> нет.
То есть только в головах разработчиков? Всех? И как контролировать
целостность
этой распределенной бд.
DM>> Giant не в счет. Просто складывется впечатление (вполне возможно
DM>> ошибочное) что над архитектурой долго не думали.
VN> В таком случае "долго не думали" вообще над всем кодом системы - вместо
VN> того чтобы строить на каждый угол мат. модели и доказывать их
VN> правильность прежде чем написать хотя бы букву:)
DM>> А в чем разница-то? функции(макросы) ХХХХ_alloc ХХХХ_read и ХХХХ_write
DM>> заказывают операцию, цепляют хук и разбирают/возвращают что
DM>> получилось. А тебе задумываться об устройстве не обязательно.
VN> Какие макросы? Как они прицепят хук, если они ждать не умеют?
VN> Весь код превращается в спагетти типа
Да умеют они ждать. Сообщения у них подразумевают ответ хотя конечно
дожидаться его не каждый обазан:
=========Beginning of the citation==============
Send a message synchronously.
void lwkt_domsg(lwkt_port_t port, lwkt_msg_t msg)
......
Waits for reply to message.
int lwkt_waitmsg(lwkt_msg_t msg)
=========The end of the citation================
Так что ничто не мешает классической реализации.
DM>> Hасколько я понял из анонса ( возможно с тех пор они изменили взгляды
DM>> ) не будет никаких локов.
VN> Или кривая передача, или враньё. Hе бывает так. Для аккуратного доступа
VN> к той же очереди сообщений (процессор выбирает чем заниматься)
VN> потребуется сериализация доступа. Сериализация - это значит лок, пусть
VN> даже типа спинлока (тут действительно спать не на чем).
Анонс этот
http://www.dragonflybsd.org/docs/pdfs/dragonflybsd.asiabsdcon04.pdf
Шедулер для lwp на каждом процессоре свой - в смысле lwp привязаны
к процессору жестко. Сериализация нужна только при постановке сообщения
в очередь порта - но и тут у них какой-то безблокировочный алгоритм
применен ( не вникал но думаю ничего сложного в атомарном добавлении
в циклический буфер нет )
VN> Раздел? Великолепно. Hо раздел входит в диск, диск висит на
VN> контроллере, а контроллер дисков иногда пользуется контроллером DMA.
VN> (Hу ладно, пусть busmastering, чтобы последнее звено убрать.) При этом
VN> между уровнем диска и уровнем контроллера есть ещё слой BIO (block
VN> input/output), у которого общая область данных на всех (тот же блок
VN> полсекунды назад требовался с другого процессора). А диск позволяет
VN> очереди запросов чтения/записи, и чтобы это работало надо уметь ставить
VN> следующий запрос пока предыдущий не закончился.
lwkt раздела передает сообщение lwkt диска, lwkt диска передает сообщение
lwkt контроллера, lwkt контроллера передает сообщение lwkt DMA.
добавь тредов по вкусу. Суть не в том что тред один а в том что если
к ресурсу невозможен одновременный доступ то с этим ресурсом
может работать только один тред.
VN> Ты всё ещё веришь в лубочную картинку с одним тредом? ;)))
Я верю что это можно построить, я готов допустить что при 100%
загрузке процессоров такая система будет производить больше полезной
работы даже чем солярис. Hо вот в том что они сумеют загрузить
равномерно процессоры я пока сильно сомневаюсь. И еще есть подозрение
что latency должен сильно увеличиться с усложнением системы.
With best regards, Dmitry Miloserdov. E-mail: dmitry@bis.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
