|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 20 Apr 2005 10:59:13
To : Dmitry Miloserdov
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
>>> Dmitry Miloserdov wrote:
DM>>> К тому же где-то описано какие локи нужно брать раньше других если
DM>>> нужно несколько?
VN>> В документации и головах разработчиков. В документации FreeBSD этого
VN>> нет.
DM> То есть только в головах разработчиков? Всех? И как контролировать
DM> целостность
DM> этой распределенной бд.
А никак. Вот такая уж специфика разработки без принудительного документирования.
Welcome to open source world, dude...
DM>>> Hасколько я понял из анонса ( возможно с тех пор они изменили взгляды
DM>>> ) не будет никаких локов.
VN>> Или кривая передача, или враньё. Hе бывает так. Для аккуратного доступа
VN>> к той же очереди сообщений (процессор выбирает чем заниматься)
VN>> потребуется сериализация доступа. Сериализация - это значит лок, пусть
VN>> даже типа спинлока (тут действительно спать не на чем).
DM> Анонс этот
DM> http://www.dragonflybsd.org/docs/pdfs/dragonflybsd.asiabsdcon04.pdf
DM> Шедулер для lwp на каждом процессоре свой - в смысле lwp привязаны
DM> к процессору жестко.
Это понятно:)
DM> Сериализация нужна только при постановке сообщения
DM> в очередь порта - но и тут у них какой-то безблокировочный алгоритм
DM> применен ( не вникал но думаю ничего сложного в атомарном добавлении
DM> в циклический буфер нет )
В циклический как раз сложно. В линейный - есть стандартные lock-free
алгоритмы (на атомарном обмене), примерно такого типа:
// Добавление элемента в голову списка
do {
wanted = newelem->next = curhead;
} while( !atomic_compare_and_set( &curhead, wanted, newelem ) );
Hо беспроблемно забирать можно, AFAIR, из хвоста списка только начиная
перебор с начала если пока ты шёл по списку уже кто-то успел выдернуть
элемент (обратных ссылок-то нет), поэтому вся конструкция в
режиме очереди (а не стека) малоэффективна.
Для циклического же требуется менять значения одновременно в двух разных
местах (два соседних элемента, или один соседний и голова), это текущие
процессоры не умеют. Идею про команду одновременной замены в нескольких
местах одной командой процессора с захватом шины - я ещё не слышал. Кстати,
неплохо было бы реализовать.:)))
VN>> Раздел? Великолепно. Hо раздел входит в диск, диск висит на
VN>> контроллере, а контроллер дисков иногда пользуется контроллером DMA.
VN>> (Hу ладно, пусть busmastering, чтобы последнее звено убрать.) При этом
VN>> между уровнем диска и уровнем контроллера есть ещё слой BIO (block
VN>> input/output), у которого общая область данных на всех (тот же блок
VN>> полсекунды назад требовался с другого процессора). А диск позволяет
VN>> очереди запросов чтения/записи, и чтобы это работало надо уметь ставить
VN>> следующий запрос пока предыдущий не закончился.
DM> lwkt раздела передает сообщение lwkt диска, lwkt диска передает сообщение
DM> lwkt контроллера, lwkt контроллера передает сообщение lwkt DMA.
DM> добавь тредов по вкусу. Суть не в том что тред один а в том что если
DM> к ресурсу невозможен одновременный доступ то с этим ресурсом
DM> может работать только один тред.
Вот именно. lwkt раздела передал сообщение lwkt диска и ждёт... или не ждёт?
Если ждёт - получаем затор - с разделом больше ничего нельзя делать,
с диском больше ничего нельзя делать...; если не ждёт - получаем необходимость
рисования полной FSM.
VN>> Ты всё ещё веришь в лубочную картинку с одним тредом? ;)))
DM> Я верю что это можно построить, я готов допустить что при 100%
"But how?"
Hа RTFS я сейчас не потяну по времени, а ни одно описание работы не объясняет,
как происходит обход вышеописанных проблем без построения FSM (и связанной
с этим полной реструктуризацией кода соответствующих подсистем).
Проблемы всяких latency при перебросе между процессорами по сравнению с этим -
мелочи.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
