Привет! Ну, я просто на-потдвердить слова UVV про олдфагов заглянул... 😊

Самый толстый справа — я.

Вообще, ЛОР немного почитал — как лет на 10 помолодел... Те же срачи, те же упоротые анонимусы (увы, далеко не везде) сносно говорящие на русском; та же школота ЛОРовским миром правит (Макском, извини, но ты мне сам говорил, что я могу в любой момент вернуться и вас всех по критиковать...).

Вообще, самое прикольное, что ЛОР — жив...

Привет,

Только что опять с UVV и его второй половинкой в кабачке посидели, и они мне этот тред показали. Я вообще поражен — Dimez, как ты меня вычислил? Мы с тобой пару раз по телефону говорили, и больше никакого личного общения не было жешь!

Даже на ЛОР зашёл, чтобы прокомментировать, первый раз лет за много...

Вообще, не совсем удачная фотка — я не всегда такой пьяный... :)

Что, и в девелопменте?

Ок, счастливо.

> Зачем?

Моя ситуация была такая: есть N процессоров и N процессов. Надо максимально эффактивно реализовать IPC.

Очевидное решение -- юзерспейсные спинлоки.

Спасибо всем ответившим!

> Используй команды movnt*.

Ну, это, типа не из Це вообще писАть...

Мне хочется такого (в идеале): есть адрес (виртуалный), валидный но "грязный" в кэше, записанный из моей любимой Це - программы, и мне надо так инвалидировать линейку кэша с этим адресом, чтобы он при этом в память не ушёл.

Подробнее начальная проблема:

Я пишу подряд в ячейки памяти, но нужны они мне только изредка. БОльшая часть записанных данных больше не пригодиться, и я знаю, какие именно. К сожалению, по техническим причинам я не могу реюзать эти адреса. Я не хочу при этом пользоваться наворотами, препятствующими загрязнению кыша; он загрязняется, гад! Вопрос -- можно ли его "почистить"?

> Хех, так самое-то интересное - это FUTEX_WAIT и FUTEX_WAKE. volatile в шаред мемори вместо со спинлоками и без всяких man 7 futex можно использовать.

Конечно, я про это и говорю.

В NTPL POSIX мутексах всё это и сделано во взаимодействии с ядрёным футекс_колл. Они без нужды в ядре не уснут...

Согласись, pthread семантика не сложнее TCP/IP...

Буквоед! :)

Ок, я раз 10 это _сделал_.

>> Футексы -- только _ИНОГДА_ ядро (когда без этого никак не обойтись)

> Эээээ... Ты уверен?

man 7 futex

(be not confused by man 2 futex)

> ...нужно использовать futex'ы, а это опять ядро ;) ...

Футексы -- только _ИНОГДА_ ядро (когда без этого никак не обойтись), в отличие от TCP/IP, который проходит через ядро, с двойной буферизацией и созданием / очисткой кучи очередей.

>> а кто сделает теперь какой-нить пример локального IPC без участия ядра?

> Никто не сделает.

Я делал...

>> Вообще, я не верю, что один человек сможет написать нечто достойное

> Emacs?

8-/? Emacs с самого начала разрабатывался довольно большой командой из MIT AI Lab, а потом в нем поучаствовали тысячи человек, соорудивших много форков. Да, дядька Столлман затеял его делать и заложил основные идеи, и то не один, но народу там сразу хватало.

> ...Это в 1.8 будет, но чтото долго оно, задерживается.

IMHO этого не надо. FS -- не БД.

На самом деле ИМХО распределённые "reliable" файлухи с транзакциями вообще не нужны. Вместо них нужны всякие распределённые БД, Берклиевские Хэши и прочие Ораклы. А распределённые файлухи нужны исключительно для скрэтчей для HPC(High-performance computing).

> Все это собирается в _один_бинарник_. ... используя TCP/IP, как средство внутреннего IPC, не изобретая бажных велосипедов. ... количество коротких (макс. 4кб) сообшений может достигать пика в 2000/сек...

:-)

Посмеялся, спасибо!

>> Вообще ИМХО "грамотный write-back кэш" для распределённой файлухи сделать невозможно. Работать-то оно, может, и будет, но тормозов добавит больше.

> Трудно сказать. Для каких-то операций наверное будет как для write-through, для каких-то быстрее (где редко нужно флашить на сервер). Наверное для случая непрерывной записи в один и тот же файл кучей клиентов будет медленнее.

Вот, боюсь, по-любому будет медленнее...

На самом деле, в распределенных файлухах, как я понял (только не принимайте мои слова слишком близко к сердцу -- я решительно не спец и вполне могу неверно интерпретировать слова, что мне говорят специалисты, когда я им жалуюсь на то, что моя аппликуха тормозит на их супре-пупер кластере), не в хэшах проблема, отнюдь...

Мне приходится работать на двух сравнительно больших (тысячи корок) кластерах с Ластрой. Разница между ними в том, что один имеет достаточное кол-во железяк для того, чтобы хранить метаданные, и динамическую маршрутизацию сетки (КвадриксНет2), а в другом оно всё (метаданные) на одном сервере лежит, и под ИБ бегает. На первом кластере я восхищён производительностью FS -- я просто не могу её насытить параллельными бенчмарками, и при этом всё летает в интерактиве! -- во втором случае всё гораздо хуже (самое неприятное -- ждать 2 минуты отклика от команды ls).

ИМХО write-back хэши -- епсилон малое . Но вот усложнить и затормозить всё они могут по самое нехочу...

> Во FreeBSD есть команда daemon(8), под Linux мне всегда ее не хватало. Отвязывает от терминала, делает chdir("/"), stdout в /dev/null, умеет pidfile - сказка.

Ну, Линуксовая setsid(8) позволяет сделать всё это и более (в кооперации с командами оболочки), см. выше.

Но обе они -- не ПОЗИКСные.

> У люстры (как и у nfs) write-through кэш, а не грамотный write-back, что равносильно тому, что кэша нет вообще - вот была главная точка зрения автора.

Ну, как-то мне эта точка зрения не импонирует.

Вообще ИМХО "грамотный write-back кэш" для распределённой файлухи сделать невозможно. Работать-то оно, может, и будет, но тормозов добавит больше.

Впрочем, я не специалист по FS. С Ластрой я работаю, и вижу, что основная проблема там в том, что она слишком сложная. Если ещё наворотов добавить то, боюсь, вообще не взлетит...

> что конкретно подразумевается под фьютексами: общая концепция man 7 futex или конкретный API man 2 futex

Концепция, конечно. API в pthread сидит.

>>> nohup ./script.sh &

> пасиба, помогло))

Это не настоящая "демонизация": у процесса остался терминал; группа, сессия и ppid остались оболочечные. Могут быть проблемы, например, если зашёл по ssh, то не выйдешь -- этот дурак будет ждать, пока все его порождения не закроют терминал.

Вот бронебойный способ, настояший демон получается:

setsid ./script.sh >/dev/null 2>&1 </dev/null

(перенаправления под башем показаны)

Почитал на опеннете обсуждение POHMELFS -- не уверен, но похоже на очередной велосипед. Есть же Lustre, которая все это с лихвой перекрывает. Автор пеняет ей на то, что Сантехники её неправильно развивают и в конце концов погубят, но как-то неубедительно...

Вообще, я не верю, что один человек сможет написать нечто достойное. Надежда на то, что коммьюнити поддержит, пока оно не слишком разрослось и обозримо -- посмотрим...

Мне тоже интересно стало...

Я, возможно, не прав, но, сдаётся мне, что концепция столь явного маппинга всех кышей на виртуальные и физические несколько устарела? Я к тому, что сейчас TLB многоуровневая и тесно завязана на конкретные кыши и (многоуровневые же) бранч предикторы, особенно в свете возрождения Nehalem'ами SMT ("гипертединга")...

> futex (man 2 futex) сразу уходит в ядро

Нет. man 2 futex :-)

Hint: "futex - Fast Userspace Locking system call"

Кстати, полезно сделать RTFM насчёт man 4 futex ;)

> Зачем тогда писать в него такой большой пост?

Судя по твоему ответу, ты тоже мало что понял ;)

> Атомарные операции есть в builtin-ах, gcc. В других компиляторах они тоже могут быть, но о переносимости придётся позаботиться руками (если надо).

Вообще-то, именно это я и написАл.

А чего я не понял -- топикстартер изначально спрашивал про атомарные типы, потом обсуждение незаметно перешло на атомарные операции. Между тем, атомарных типов -- сколько угдно (де-факто для почти всех компиляторы на почти всех платформах можно смело полагать любой целый тип атомарным), а атомарных операций нет ни в стандарте, ни в "стандарте де-факто". Даже интринсики у одного и того же компилятора могут различаться на разных платформах. Проще всего заюзать готовую библиотеку -- я ссылку привёл.

> Атомарные операции на мьютексах -- результат фатального и необратимого поражения головного мозга.

Во-первых, обкладка некими блокировками атомарных операций -- единственный способ, если оставаться в рамках POSIX'а. В Линуксе с ядром >=2.5 разницы между мутексами и спинлоками практически не будет.

Во-вторых, атомарная операция -- не самоцель, а необходимая для алгоритма фенечка. В 90% случаев атомарные арифметические операции нужны для "атомизации" более "толстых" операций, а мутексы для этого и придуманы. Судя по нежеланию топикстартера уходить в ядро, именно это ему и надо. Так вот, с современным линуксовым ядром мутекс в ядро и не пойдет, если можно, в юзерспейсе спинлок крутанёт.

Оффтопик (спам?):

http://www.linux.org.ru/view-message.jsp?msgid=3487627