|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Miloserdov 2:5020/400 21 Apr 2005 18:47:25
To : Valentin Nechayev
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
Hello, Valentin!
You wrote to me on Wed, 20 Apr 2005 06:59:13 +0000 (UTC):
DM>> То есть только в головах разработчиков? Всех? И как контролировать
DM>> целостность
DM>> этой распределенной бд.
VN> А никак. Вот такая уж специфика разработки без принудительного
VN> документирования. Welcome to open source world, dude...
DM>> Сериализация нужна только при постановке сообщения
DM>> в очередь порта - но и тут у них какой-то безблокировочный алгоритм
DM>> применен ( не вникал но думаю ничего сложного в атомарном добавлении
DM>> в циклический буфер нет )
VN> В циклический как раз сложно. В линейный - есть стандартные lock-free
VN> алгоритмы (на атомарном обмене), примерно такого типа:
[....]
VN> Для циклического же требуется менять значения одновременно в двух
VN> разных местах
Ты про циклический список а там буфер. Отличия - фиксированная длина
добавление возможно только в хвост извлечение только из головы.
При этом извлечение сериализовано автоматически - читатель-то один.
Hапример так:
struct msg* msgbuf[MAXMSGS];
const int wrap=(INT_MAX/MAXMSG)*MAXMSG;
int head,tail;
void push(msg*m)
{ int cur;
do {
cur=tail;
if(cur==head+MAXMSG-1 || head+MAXMSG-1-cur==wrap)
{ _switch(); /* буфер полон */ }
} while(!atomic_compare_and_set( &tail, cur, (cur+1)%wrap ) );
if( ! atomic_compare_and_set( &msgbuf[cur%MAXMSG], 0, m ) ) )
{ /* тут скорее всего нужно вставить assert */ }
}
mgs * shift()
{
msg *m;
m=msgbuf[head%MAXMSG];
if(m) { msgbuf[head%MAXMSG]=0; head=(head+1)%wrap; }
return m;
}
При желании shift тоже переделывается для нескольких читателей.
Если MAXMSG это 1<<n то wrap не нужен.
Hаверное если сделать rtfs то можно увидеть более красивое решение.
VN> Вот именно. lwkt раздела передал сообщение lwkt диска и ждёт... или не
VN> ждёт? Если ждёт - получаем затор - с разделом больше ничего нельзя
VN> делать, с диском больше ничего нельзя делать...; если не ждёт -
VN> получаем необходимость рисования полной FSM.
Hу зачем же крайности можно микрошедулер внутри треда сделать благо
опыт тредов freebsd4 еще не забыт ;). stack&state делать не per-lwkt а
per-message
там где это нужно. Гарантия что к глобальным данным нет конкурирующего
доступа остается так как из sub-треды в работе не более одной причем
все спящие sub-треды уснули по собственному желанию а не вытеснением.
Вариант с "ждем" тоже не фатально плох - это все равно очень большой
шаг вперед от 4.x с Giant по любому поводу. По сравнению с 5кой тоже
есть плюсы - там где в 5ке стоит faculty-based mutex при входе, dragonfly
выиграет из-за возможности распараллеливания "отправной точки" по
нескольким процессорам ( там где не распараллелят все равно будет не
хуже 5ки ). Там же, где в 5ке сумели ограничиться коротким мутексом
и от точки входа до выхода сумели не трогать Giant, 5ка вроде бы должна
смотреться лучше, правда это произошло скорее всего из-за того что
вызов был ошибочен и никакой полезной работы сделано не было.
Вышесказанное это ничем не подтвержденное личное предположение.
With best regards, Dmitry Miloserdov. E-mail: dmitry@bis.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
