>> Не скажу, что я часто менял компиляторы, но в своем коде я такого не встречал ни разу. Примеры привести можешь?

> Чтоб далеко не ходить, http://www.linux.org.ru/view-message.jsp?msgid=3880660

Да ну, фигня... любой компилятор с серьезным оптимизатором мог так лажануться. Это не зависит от входного языка.

>> Или он и в самом деле это знает.

> Если он не взботнул хотя бы 550 страниц Стандарта, знать этого он не может.

А... начинает брезжить тусклый свет понимания. Долго объяснять, почему ты не прав. Краткая версия - правило 80/20 и понимание основ работы машины. И кстати, стандарт - это руководство компиляторщикам :)

>>> с posix та же хрень. Не слишком эффективный по отношению к аппаратуре

>> Фигасе. Раскрой тему, а? Я драйверы пишу, если что. Хочу знать, как POSIX мне мешает.

> Например, поковыряй в окрестностях этого поста: http://lkml.org/lkml/2009/3/27/310

Это ограничения ext3 (и, может быть, ext4). К POSIX особого отношения не имеет, следи за работой по data=guarded. И поверь мне на слово, выражение "не слишком эффективный по отношению к аппаратуре" было крайне неудачны :) К аппаратуре это не имеет никакого отношения.

Mustread перед радикальными заявлениями о POSIX в Linux: http://lwn.net/Articles/351422/ http://lwn.net/Articles/328363/

> За то в posix есть fsync, который предоставляет больше гарантий, но за то убивает производительность.

В POSIX есть fdatasync, который как раз то, что нужно, но мало кто о нем знает :)

> Проблема в том, что он предоставляет api, располагающий к некорректному использованию. Недавний срач вокруг ext4, говенного userspace софта и обнулившихся файлов - тому подтверждение.

Ну, ссылки выше. Если ты и после чтения будешь винить POSIX - можешь смело изобретать свой интерфейс ОС. У тебя всё получится :)

>> начала 80-х

>Тут этот флейм всякий раз возобновляется, как только выйдет новая версия fpc или lazarus

При всём уважении к ЛОРу, в том флейме отметились парни покруче - от Кернигана до Джехани с Хоаром :)

> Да ну, фигня... любой компилятор с серьезным оптимизатором мог так лажануться. Это не зависит от входного языка.

Это не компилятор лажанулся. С неформальной точки зрения, компилятор повел себя логично. Лажанулся автор кода, тк не очень хорошо знает хитровывернутый стандарт.

> Долго объяснять, почему ты не прав.

И даже если ты попробуешь объяснить, объяснение получится неубедительным. В Си очень часто не догадываешься, где и в какую "фичу" языка ты вляпался. Код net/tun по ссылке кажется вполне невинным, на первый взгляд.

> Краткая версия - правило 80/20

Знание 80% языка Си позволяет избежать лишь 20% подводных камней. Ага?

> и понимание основ работы машины.

Использовать "понимание основ работы машины" - грубая ошибка. На Си "основы" никаким боком не распространаяются. Могу привести пару примеров кода, когда такое "понимание" выливается в undefined behaviour или, что еще хуже, в противоречивое толкование одного и того же кода программистом и компилятором.

> И кстати, стандарт - это руководство компиляторщикам :)

Стандарт Си - это долбаный талмуд, который нужно зазубрить каждому программисту Си, если тот хочет писать корректный код. По-другому не выйдет. И именно поэтому язык Си не годен и должен быть замещен чем-то более вменяемым.

> И поверь мне на слово, выражение "не слишком эффективный по отношению к аппаратуре" было крайне неудачны :) К аппаратуре это не имеет никакого отношения.

Имеет самое прямое отношение. Природа дискового накопителя такова, что для эффективной работы приходится хранить данные и метаданные раздельно, откладывать и переупорядочивать записи на диск. Ключевое свойство состоит в том, что информация дробится на мелкие кусочки, и разные кусочки записываются на носитель совсем не в том порядке, в котором пользователи заказывали запись.

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

POSIX-овый fsync гарантирует, что по его завершении данные фактически окажутся на поверхности диска, а метаданные будут обновлены. Вкупе с атомарным rename этого хватает, чтобы гарантировать консистентность файлов. Но немедленная, синхронная запись на диск ломает всю малину с переупорядочиванием записей - и получается долго и очень дорого. Ровно таким же недостатком обладает и fdatasync.

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

Средствами posix эффективно использовать аппаратуру нельзя. Ты или лишаешься гарантий относительно своих файлов, либо получаешь неоправданное снижение производительности

> можешь смело изобретать свой интерфейс ОС. У тебя всё получится

У меня не получится. И ни у кого с наскоку не получится. Нужны исследования, и эти исследования ведутся. В том числе, авторами стрекозы.

> Лажанулся автор кода, тк не очень хорошо знает хитровывернутый стандарт.

Стандарт (и его знание/незнание) не виноват. Человек сделал ошибку, оптимизатор ее усугубил.

> В Си очень часто не догадываешься, где и в какую "фичу" языка ты вляпался. Код net/tun по ссылке кажется вполне невинным, на первый взгляд.

[устало] никакие фичи Си тут ни причем. Это человеческая ошибка, усугубленная оптимизатором в бэкенде компилятора. Ровно то же могло случиться с компилятором Oberon.

>> Краткая версия - правило 80/20

> Знание 80% языка Си позволяет избежать лишь 20% подводных камней. Ага?

Не угадал.

> Средствами posix эффективно использовать аппаратуру нельзя. Ты или лишаешься гарантий относительно своих файлов, либо получаешь неоправданное снижение производительности

Если ты не изменил этого мнения, прочитав статьи по ссылкам, которые я дал, и прочитав man fdatasync, мне нечего тебе сказать.

> Нужны исследования, и эти исследования ведутся. В том числе, авторами стрекозы.

Диллон не собирается изобретать замену POSIX.

> Это человеческая ошибка, усугубленная оптимизатором в бэкенде компилятора. Ровно то же могло случиться с компилятором Oberon.

Язык Си зачастую контр-интуитивен. И эта "ошибка" - пример такого контр-интуитивного поведения. С более вменяемым языком никакой ошибки не было бы.

> [устало]

Раз эта беседа так тебя утомила, продолжать не буду. Тем более, что оффтопик.

> Если ты не изменил этого мнения, прочитав статьи по ссылкам, которые я дал, и прочитав man fdatasync, мне нечего тебе сказать.

Прочитал статьи, но не комменты к ним. И man 2 sync тоже на всякий случай перечитал. Свою позицию я подробно аргументировал. Обсуждение fbarrier авторами ФС на lkml показал. Нечего - значит, нечего...

> Диллон не собирается изобретать замену POSIX.

Он _уже_ сделал асинхронный API. Считаешь, что это ничем не отличается от POSIX - считай. Полагаю, что обмен мнениями по этому вопросу также состоялся :)

s/man 2 sync/man 2 fsync/

>Язык Си зачастую контр-интуитивен

Ты наверное ножиком по пять раз на дню режешься

> Свою позицию я подробно аргументировал.

O_o

>> Диллон не собирается изобретать замену POSIX.

> Он _уже_ сделал асинхронный API.

И больше ему ничего не надо. Если ты считаешь, что это будет сильным усовешенствование POSIX - ок, дело твое.

>> Свою позицию я подробно аргументировал.

> O_o

Вот тут: http://www.linux.org.ru/jump-message.jsp?msgid=4071750&cid=4074681 , 5 абзацев, начиная со слов "Имеет самое прямое отношение"

> Вот тут: http://www.linux.org.ru/jump-message.jsp?msgid=4071750&cid=4074681 , 5 абзацев, начиная со слов "Имеет самое прямое отношение"

Кроме абзаца про fbarrier (а этот системный вызов признан ненужным), это материал курса "Файловые системы 101". Его вообще не нужно излагать.

Кстати, вот это:

> Использовать "понимание основ работы машины" - грубая ошибка. На Си "основы" никаким боком не распространаяются. Могу привести пару примеров кода, когда такое "понимание" выливается в undefined behaviour

было бы интересно.

Хочу слышать мнение izena про этот дистрибутив.

> Кроме абзаца про fbarrier (а этот системный вызов признан ненужным)

Я объяснил, почему он нужен. Можешь объяснить, почему - нет? По твоим ссылкам я ничего такого не приметил.

> это материал курса "Файловые системы 101". Его вообще не нужно излагать.

Не у всех был курс 101 :) Мне вот кажется абсолютно естественной такая вещь, как barrier. В подсистемах памяти некоторых микропроцессоров она также используется (еще ее называют memory fence). http://en.wikipedia.org/wiki/Memory_barrier

>> Использовать "понимание основ работы машины" - грубая ошибка. На Си "основы" никаким боком не распространаяются. Могу привести пару примеров кода, когда такое "понимание" выливается в undefined behaviour

> было бы интересно.

Вот в Стандарте написано, что signed overflow - это Undefined Behaviour. Почти каждый программист говорит, что UB здесь связан с извратной реализацией signed чисел на некоторых архитектурах. А у нас на x86 знаковые числа представлены в дополнительном коде, и всем известно, что на x86 делают инструкции add/sub/inc/dec. Так что, якобы, никакого UB нет. В качестве аргумента приводят программку с распечаткой переменной до и после signed overflow. Каково же их удивление, когда собранная gcc -O2 программа int main() { int i; for(i = 1; i > 0; i+=100000) ; return 0; } наглухо виснет! А собранная gcc -O0 - завершается! :D

Мораль: компилятор срать хотел на наши познания о процессорной архитектуре, о двоичном представлении на ней отрицательных и положительных чисел, и вообще на всё срать хотел. Достаточно одной оговорки в Стандарте, как он начинает использовать ее для агрессивных оптимизаций.

Другая история. Вот есть у меня две беззнаковых ненулевых 16-битных переменных. Таких, что их сумма (по модулю 2^16, естественно) равна 0. Что будет, если я сложу их? Очевидно, 0. Согласны?

Проверяем:
#include <stdint.h>
#include <stdio.h>
int main()
{
uint16_t a = 1;
uint16_t b = 0 - a;
uint16_t c = a + b;
printf("%d+%d=%d\n", (int) a, (int) b, (int) c);
printf("%d\n", (int) (a+b));
return 0;
}

Мораль: компилятор срать хотел на наши представления о 16-битных числах, о поддержке арифметики с такими числами на нашем процессоре, и тд. У него в стандарте написано: integer promotion. Всякий раз, как он складывает два беззнаковых, размер которых меньше unsigned int, он каждое из них кастует к unsigned int. Не скастовал программист сумму вручную к uint16_t - сам дурак. Не очевидно? А Стандарту на это посрать. Более того, результат второго printf-а таки зависит от архитектуры! Если на ней unsigned int имеет размер 16 бит, то распечатается 0.

> Вот в Стандарте написано, что signed overflow - это Undefined Behaviour. [...] Каково же их удивление, когда собранная gcc -O2 программа int main() { int i; for(i = 1; i > 0; i+=100000) ; return 0; } наглухо виснет! А собранная gcc -O0 - завершается! :D

Я вот только не понял, причем тут overflow. В ассемблере от gcc -O2 просто нет никаких сложений. И overflow там нет.

А если пойнт в том, что рассчитывать на overflow глупо, то с этим будут спорить только те, кто считает себя очень умными (но таких вообще надо держать либо под контролем, либо подальше от работы).

> Проверяем:

Ы? Вычитание uint16_t, потом приведение его к signed int - это такой способ напроситься на неприятности?

> Вычитание uint16_t

Вот ведь казалось бы, сумма двух uint16_t - это uint16_t? И если он равен нулю, не все ли равно, к чему его потом кастовать? :D

> приведение его к signed int - это такой способ напроситься на неприятности?

Приведение к int - это способ скормить его printf-у. Если хочешь, приведи к unsigned int - результат не изменится.

Пример выдран из куска кода, где вместо кастования делался свдиг суммы вправо, результат присваивался назад в uint16_t. Естественно, резульат был не таким, какой ожидал программер.

> А если пойнт в том, что рассчитывать на overflow глупо

О как! То есть использование аппаратной арифметики по модулю 2^n вдруг оказалось под запретом? :D А ничего, что без этого некоторые алгоритмы сильно теряют в эффективности? Может, и побитовые операции еще запретим? :D

А поинт в том, что "понимание основ работы машины" никак не коррелирует с поведением компилятора. Компилятор агрессивно использует Стандарт, а Стандарт в свою очередь ориентирован в том числе и на весьма экзотические машины. Которые не дают тех гарантий, что дают привычные всем современные процессоры.

> Ты наверное ножиком по пять раз на дню режешься

О Великий Анонимус, прости мне эту дерзость, но я пользуюсь в основном столовыми ножами. Они тупы настолько, что даже отбивную режут с трудом. За последние 20 лет мне ни разу не удалось как следует себя порезать. Радость моя по этому поводу омрачена тем ужасным фактом, что я вынужден тебя разочаровать.

> За то я видел много кода, который от смены компилятора вдруг менял свое поведение.

За write only код нужно руки отрывать.

А товарищей, которые любят писать что-нибудь типа i++ + ++i, лично готов убить.

> Видел код, где программист имел ввиду одно, а компилятор понял совсем другое

Принцип KISS тоже никто не отменял :-) Не уверен — пиши проще, практически беспроигрышный вариант.

> Код net/tun по ссылке кажется вполне невинным

NULL pointer derefernce — хренасе невинный. Автор кода подумал за компилятор, за что и поплатился.

> В Си очень часто не догадываешься, где и в какую "фичу" языка ты вляпался.

Опять же, что мешает писать проще? Это относится не только к C, а к любому языку.

> Стандарт Си - это долбаный талмуд, который нужно зазубрить каждому программисту Си, если тот хочет писать корректный код.

Ыыы... А стандарт C++ — это вообще всем талмудам талмуд :-)

> Вся возня - внутри кэша записи - fbarrier лишь накладывает относительно слабые ограничения на переупорядочивание записей.

А в чем разница write()/fbarrier()/close()/rename() vs write()/fdatasync()/close()/rename()?

> Не скастовал программист сумму вручную к uint16_t - сам дурак. Не очевидно?

Свои правила есть во всех языках программирования, и их просто надо знать. Тот же type promotion есть в ненавистном многим Паскале, причем в 7-м ТрупыПоскакале были весьма хитрые правила: если в хорошем арифметическом выражении смешать Int-типы разной длины (например, ShortInt, Integer и LongInt), для корректного результата нужно было делать явное приведение типов. Опять же, либо учи правила языка, либо пиши проще.

Я не совсем понял, что имела своей целью показать программа, ибо 65536 mod 2^16 = 0. Если бы получался результат, который после приведения не был бы равен нулю, то другое дело. А так по модулю разрядности uint16_t результат вполне корректный.

> Проверяем:
#include <stdint.h>
#include <stdio.h>
int main()
{
uint16_t a = 1;
uint16_t b = 0 - a;
uint16_t c = a + b;
printf("%d+%d=%d\n", (int) a, (int) b, (int) c);
printf("%d\n", (int) (a+b));
return 0;
}

------------------------------------------------
:)))

printf("%d\n", (int) (a+b));
меняем на
printf("%u\n", ((int) (a+b)));

и все фокусы и чудеса закончились

>> Существенным недостатком системы субъективно считаю сложность мат-модели

>Можно попросить линк на мат модель? В википедии ссылка на первоисточник дохлая. Ковыряться в официальном сайте - не Ъ.

Я немного плоховато сформулировал это предложение. Да мат-модель ядра стрекозы принципиально другая чем во всех монолитных ядрах. Для пользователя это выглядит так что на каждом проце есть свой менеджер процесов, а общего менеджера процесов для всей ситсемы как в юниксах или в NT нету, само ядро стрекозы может запускаться как обычный пользовательский процес и обслуживать пользовательские процесы (VM, кластер эдиного системного образа). Реализация этого настолько сложна что стрекоза использует своё уникальное API на котором никто кроме пару сотен хакеров её ядра програмировать не может -- ибо очень сложно... По этому в стрекозе существует специальная прослойка, фактически эмулятор unix API в котором работают все программы... Тоесть найтивных программ для стрекозы практически нет, а все 6000 пакетов работают в эмуляторе юникса. К стати система спроэктирована так что эмуляторы API можно подстёгивать любые...

класс! оно еще живо ... ушел тестировать.

Пока будут половозрелые сексуально неудовлетворённые юноши, оно будет жить. Я гарантирую это.

>Можно попросить линк на мат модель? В википедии ссылка на первоисточник дохлая. Ковыряться в официальном сайте - не Ъ.

Гуглить надо +lwkt +DragonFly +BSD

вот кажись найболее подходящая для вас ссылка:

http://citkit.ru/articles/68/

Для Ъ

"DragonFly - модель легковесных нитей ядра

Оригинал: The Light Weight Kernel Threading Model Перевод: Lao редакция от 05.06.01 1-я редакция от 05.01.31 - Unix.ginras.ru

7 июня 2005 г Модель легковесных нитей ядра

В основе DragonFly лежит модель легковесных нитей (threads) ядра (LWKT, Light Weight Kernel Threading). Для каждого процесса в системе имеется ассоциированная с ним нить, а большинство процессов ядра - это фактически всего лишь чистые нити. Например, демон pageout (вытеснения страницы из ОЗУ) - это чистая нить без контекста процесса.

У модели LWKT имеется ряд ключевых особенностей, независимых от архитектуры. Эти особенности были разработаны для устранения или сокращения конкуренции между процессорами.

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

2. Нить никогда не будет вытеснена на другой процессор, пока она выполняется в ядре, и нить никогда не будет перемещаться между процессорами, когда она блокирована. Планировщик пользовательского уровня может переместить нить, выполняющуюся пользовательском режиме. Нить никогда не будет переключена через вытеснение непрерываемой нитью. Если прерываемая нить вытесняет текущую нить, то в момент, когда прерываемая нить завершает свое выполнение или блокируется, вытесненная нить возобновляет выполнение независимо от своего состояния с точки зрения планировщика. Например, нить может быть вытеснена после вызова lwkt_deschedule_self(), но это произойдет раньше, чем она реально отключится. И это правильно, потому что управление будет возращено ей непосредственно после того, как прерываемая нить поток завершит свое выполнение или блокируется.

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

4. Процессор, который пытается планировать нить, принадлежащую другому процессору, для выполнения операции будет посылать целевому процессору сообщения основанные на IPI. Эти сообщения асинхронны по умолчанию, и хотя IPI могут обладать некой латентностью, они не обязательно растрачивают вхолостую циклы по этой причине. Нити могут заблокировать подобные операции путем входа в критический участок, что фактически и делает LWKT-планировщик. Вход в критический участок и выход из него считаются экономными операциями и не требуют ни блокировки, ни выполнения команд блокирования шины.

5. Подсистема сообщений IPI работает со взаимными блокировками FIFO, путем прокручивания и обработки очереди входящих сообщений в ожидании разгрузки очереди исходящих сообщений. В этих условиях подсистема сообщений IPI специально не переключает нити, что позволяет программе воспринимать ее как неблокирующий API, хотя может происходить прокручивание.

В дополнение к этим ключевым особенностям, модель LWKT позволяет производить вытеснение по FAST-прерываниям И вытеснение по нитиевым прерываниям. FAST- прерывания могут вытеснять текущую нить, когда она не находится в критическом участке. Нитиевые прерывания также могут вытеснять текущий поток. Система LWKT будет переключаться в режим нитиевых прерываний, а потом - обратно в исходное состояние, когда нитиевое прерывание блокируется либо завершает работу. Действие функций IPI очень похоже на действие FAST-прерываний. В DragonFly это в полной мере используется в SYSTIMERS API для распределения прерываний hardclock() и statclock() между всеми процессорами. Подсистема IPI для работы с сообщениями

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

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

Подсистема IPI интенсивно используется не менее чем в шести основных подсистем LWKT, включая внутрипроцессорное планирование нитей и подсистемы обмена сообщениями. Поскольку система IPI является прирожденной для DragonFly, в ней не требуется и не используется механизм Big Giant Lock (как во FreeBSD). Поэтому все функции, основанные на IPI, должны быть МР-безопасными (и они таковыми являются). Основанная на IPI подсистема синхронизации процессоров

В модели LWKT используется обощенный, машиннонезависимый API синхронизации процессоров. Этот API может использоваться для перевода целевых процессоров в известное состояние, пока ведется работа с чувствительной структурой данных. Этот интерфейс, прежде всего, применяется при обновлении таблиц страниц устройства управления памятью (MMU). Например, небезопасно проверять и очищать бит модификации в элементе таблицы страниц, а потом удалять этот элемент, даже сохранив соответствующую блокировку. Это потому, что пользовательский процесс, выполняющийся на другом процессоре, может обращаться к этой таблице и изменять ее, из-за чего возникнет соревнование между образом буфера быстрого преобразования адреса (TLB) на целевом процессоре и вашими попытками очистить элемент таблицы страниц. Правильное решение состоит в том, чтобы сначала перевести в известное состояние все процессоры, которые могут произвести выталкивание из TLB в элемент таблицы страниц (т.е. все процессоры в маске pm_active pmap'а), провести модификацию, после чего освободить процессоры с запросом на объявление недействительными их TLB.

API, реализованное в DragonFly, свободно от взаимных блокировок. Действия по синхронизации нескольких процессоров могут выполняться параллельно, и это распространяется на все нити, которые обрабатывают событие ссинхронизации, на время этой обработки. Даже при наличии этой гибкости, поскольку интерфейс синхронизации процессоров работает в контролируемой среде, функции обратного вызова (callback) работают подобно функциям используемым в подсистеме сообщений IPI. Сериализующие маркеры

Сериализующий маркер (serializing token) может удерживаться одновременно несколькими нитями. Для нити, удерживающей сериализующий маркер, гарантируется, что одновременно с ней не будет выполняться ни одна нить с тем же маркером.

Нить может удерживать любое число сериализующих маркеров.

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

Теоретически при использовании механизма сериализующих маркеров нет неразрешимых проблем со взаимной блокировкой. Тем не менее, в начальной реализации могут проявляться проблемы, связанные с удержанием нескольких маркеров.

Сериализующие маркеры может также использоваться для защиты нитей от вытеснения прерываниями, стремящимися получить тот же маркер. Этот эффект несколько отличается от механизма Big Giant Lock (также известной под названием МР-блокировки), который не обеспечивает блокировку для защиты от вытеснения прерываниями на том же самом процессоре. Важно заметить, что атомарность маркера сохраняется в условиях вытеснения, даже если вытеснение предполагает временное переключение на другую нить. Для того, чтобы сохранить атомарность маркера, нет необходимости входить на уровень spl() либо в критический участок.

Удержание сериализующего маркера не гарантирует отсутствие вытесняющих прерываний, хотя и может заставить некоторые из них блокироваться с перепланированием. В не-нитиевых прерываниях FAST и IPI не допускается использование маркеров, так как для них отсутствует контекст нити. В этих подсистемах используются блокировки на основе критических участков."

>Видите ли... Фундаментальные недостатки неоклассических ядер пока не перевешивают недостатки Стрекозы как крайне непопсовой системы. Если считать априори, что аудитория фрюниксов хотя бы наполовину состоит не из хомячков, и что она принимает решения осознанно, можно сказать, что хороший дизайн (в смысле архитектура) для системы значит не так много, как хотелось бы. Если допускать здоровый цинизм, то при всех отдельных достоинствах различных BSD систем, а также опенсоляриса, Linux остаётся наиболее обжитой и безпроблемной системой из FOSS OS. Пока что это перевешивает всё остальное. Почему так вышло? В лицензии ли тут дело, или в мировом заговоре, но из фриниксов только Линукс может пока считаться реальным конкурентом венде на любых фронтах.

Да лицензия бсдишек мне не нравится! Да Линукс сегодня занят только конкуренцией с виндой и в этой войне забывает обовсём... короче ребята заигрались и положение дел в этом плане будет только усугублятся...

В бсдишек сообщество ставит другие цели, они конкурируют не с виндой, а с Линуксом... причём если есть свежие идеи и сотня другая хакеров которые эти идеи считают правильными, то форк делают автоматом...

Мат-одель lwkt не есть тривяльна и очевидна.. её не все поняли и произошол вполне закономерный форк..

Сегодня ценность DragonFly BSD есть в том что она ЕДИНСТВЕННАЯ демонстрирует другую мат модель пшланировщика задач. А то придумали монолитное ядро юникса с "запором" в начале 70х, спер билл ядро бсдюхи с "запором" для своей NT и больше ничего (кроме крайне неудачной модели микроядер) не делалось...

Интерестная система, жаль для установки в виртуалке для hammera сегодня надо не мение 50Гб -- прожорливый пока однако...

>Интерестная система, жаль для установки в виртуалке для hammera сегодня надо не мение 50Гб -- прожорливый пока однако...

Чушь какая-то. Я в виртуалку ставил DFBSD на 4-гигабайтный HAMMER-раздел. Система работала и даже мгновенные снимки автоматом делала.

>автор и идеолог Диллан, категорически не согласился с изменениями в ядре FreeBSD 5.0 и форкнул её уведя с собой ~200 разработчиков freebsd

Правильно. Нефиг с педерастами водиться.

>Чушь какая-то. Я в виртуалку ставил DFBSD на 4-гигабайтный HAMMER-раздел. Система работала и даже мгновенные снимки автоматом делала.

В какую виртуалку какую версию DragonFly BSD ???

http://www.dragonflybsd.org/issues24/

"VirtualBox (and maybe VMWare too) do not implement the hard disk synchronize_cache command so a panic or hard shutdown may corrupt the filesystem. Because of this and also the fact that most user-specified hard drives are not the 200GB minimum recommended for HAMMER, we recommend that you install UFS on the virtual hard drive and not HAMMER."

GNUFun> Ты мне скажи чем Альт лучше других Линукс..

Стабильностью, надёжностью, хорошей поддержкой железа, не слишком, но довольно новым набором ПО, возможность говорить с разработчиками на русском, хорошей сборкой пакетов.

GNUFun> Чем хуже не надо, это и так все знают...

И чем, если не секрет?

GNUFun> А вы не с альта? Я вспомнил ваш предидущий аватар "пингвина с молотком" и у меня это вызвало определённые асоциации.

У противников генетически модифицированных продуктов и более нездоровые ассоциации бывают.

GNUFun> А я с генты которая лучше и быстрее деба

Ага. На 3% быстрее. Но если учесть затраченное время на компиляцию, которое можно пустить на работу программ - реально имеются потери производительности.

Manhunt> oberon.

Оно серьёзно где-нибудь используется? Вот Limbo - в Embedded используют вовсю. А Oberon?

Manhunt> как должно быть устроено следующее поколение FOSS

Используй Inferno - она под GPL. Да и дальше Inferno никакая ОС так и не ушла в развитии.

> и все фокусы и чудеса закончились

Где?? Ты проверял? Предложенная тобой замена на результат не влияет.

> Тут я хочу в очередной раз плюнуть в спину тем, кто не знает про sequence points в си; и тем, кто не проверяет код возврата системного вызова close; и тем, кто полагает, что системный вызов write не может завершиться после записи только части буффера; и тд и тд - многие даже не догадываются, что их код по пояс в дерьме.

Это недвусмысленный намек на EINTR? Так оберточки делать надо. По-моему о таких вещах в каждой книжке про POSIX написато.

>В какую виртуалку какую версию DragonFly BSD ???

В QEmu гонял версию 2.0 или 2.2.

> Ты мне скажи чем Альт лучше других Линукс.. Чем хуже не надо, это и так все знают...

Очевидно же, русишфикацией!

> Но в отличие от fsync, это не требует немедленного обращения к жесткому диску (можно даже шпиндель не раскручивать). Вся возня - внутри кэша записи - fbarrier лишь накладывает относительно слабые ограничения на переупорядочивание записей.

При fsync() никакого немедленного обращения к диску не происходит. Вего навсего, данные, находящиеся в страничном кэше, относящиеся к этому файлу, немедленно отправляются на уровень блочной подсистемы. Ни больше, ни меньше. А дальше, в каком порядке что записывать, решает планироващик ввода/вывода блочной подсистемы. И опять же, делается это отнюдь не немедленно. Обычно, величина таймаута для write запросов составляет порядка 5 ms.

> форкнул её уведя с собой ~200 разработчиков freebsd

> форкнул её уведя с собой ~200 разработчиков freebsd

"Шарик, ты балбес" (c) Если по-сути, то не кури голубинный помёт до обеда.

>>> Создания не-POSIX API для userspace здесь просто нет.

>> Всему свое время.

>А, ну если речь идет о неопубликованных для широкой публики планах, тогда ой. Но я думаю, что Диллону даже по опубликованным целям хватит работы еще на годы.

Ещё раз для всех кто в танке!!!

Ядро стрикозы не есть POSIX написано с нуля и имеет собственный НЕ POSIX API!!!!!!!!!!!!

Стрикоза, помня что время сделало со всеми не POSIX системами кроме вантуза имеет СВОЙ ЭМУЛЯТОР POSIX API для работы пользовательских програм... И дело програмиста использовать посикс для портируемости между юниксами или родной API ядра DragonFly BSD... К стати можно тап прицепить прослойку и win API... ядро стрекозы изменять не надо, а пользовательские проги будут виндовые..................

>>> Создания не-POSIX API для userspace здесь просто нет.

>> Всему свое время.

>А, ну если речь идет о неопубликованных для широкой публики планах, тогда ой. Но я думаю, что Диллону даже по опубликованным целям хватит работы еще на годы.

Ещё раз для всех кто в танке!!!

Ядро стрикозы не есть POSIX написано с нуля и имеет собственный НЕ POSIX API!!!!!!!!!!!!

Стрикоза, помня что время сделало со всеми не POSIX системами кроме вантуза имеет СВОЙ ЭМУЛЯТОР POSIX API для работы пользовательских програм... И дело програмиста использовать посикс для портируемости между юниксами или родной API ядра DragonFly BSD... К стати можно тап прицепить прослойку и win API... ядро стрекозы изменять не надо, а пользовательские проги будут виндовые..................

Да и вообще, SSD уже не сегодня завтра дисковые накопители вытеснит, и проблема эта уйдёт в принципе.

> Не уверен — пиши проще, практически беспроигрышный вариант.

А как понять, в чем можно быть уверенным, а в чем - нет?

> NULL pointer derefernce — хренасе невинный. Автор кода подумал за компилятор, за что и поплатился.

Автор кода был уверен, что в режиме ядра обращение по адресу 0 никаких ужасных последствий не вызовет. Пиши он на ассемблере, так оно и было бы...

Откуда ему было догадаться, что из его кода компилятор сделает вывод о ненулёвости указателя? И не смотря на явно прописанную проверку на нуль, нроверять ничего не станет? Учитывая, что это поведение зависит от версии компилятора и опций оптимизации, единственный способ - читать-читать-читать долбаный стандарт. И то хрен догадаешься.

> Ыыы... А стандарт C++ — это вообще всем талмудам талмуд :-)

Угу :)

> Свои правила есть во всех языках программирования, и их просто надо знать.

В том вся и беда, что долбаных правил - 550 страниц. И даже внимательного их прочтения не достаточно для ясного понимания "что можно, а что нельзя".

Де факто же эти правила мало кто читает. Проверяют, что код вроде бы работает с текущей версией компилятора - и на этом всё.

> Если бы получался результат, который после приведения не был бы равен нулю, то другое дело.

Чтобы получить такой результат, надо поделить сумму на 2 :) До приведения, естественно.

> Я не совсем понял, что имела своей целью показать программа

Программа имела целью показать, что в случае с Си нельзя полагаться на интуитивное "понимание основ работы машины". Исходя из такого "понимания" должны были сложиться два 16-битных регистра, и автоматически сумма должна быть по модулю 2^16. Стандарт же считает иначе.

> А в чем разница write()/fbarrier()/close()/rename() vs write()/fdatasync()/close()/rename()?

В том, что fdatasync "записывает на диск содержимое всех буферов данных, связанных с файлом, причем возврат из функции происходит только после того, как это было сделано". А fbarrier никаких немедленных записей не вызывает. Поэтому fbarrier оставляет планировщику IO гораздо больше возможностей для оптимизации.

> Это недвусмысленный намек на EINTR? Так оберточки делать надо. По-моему о таких вещах в каждой книжке про POSIX написато.

Ага, на него. Ага, надо. И еще много чего надо. Но люди этого не делают. Пруф - срач вокруг ext4 и понулившихся файлов.

И в том, что всё так плохо, виноват по моему мнению, POSIX. Вот располагает он к некорректному использованию себя.

Давай сравнение генты, деба и альта оставим для другого раздела. А здесь сравниваем: ЯДРА, МАТ_МОДЕЛИ, API, микроядра, монолитные ядра, неокласические ядра и lwkt...

>Ядро стрикозы не есть POSIX написано с нуля и имеет собственный НЕ POSIX API!!!!!!!!!!!!

Чем больше восклицательных знаков в предложении, тем чаще оно оказывается ложным.

Во-первых, слово стрекоза пишется е.

Во-вторых, загляни в исходники ядра и посмотри копирайты. Там очень много копирайтов от FreeBSD. Значит ядро DF BSD написано не с нуля.

>В QEmu гонял версию 2.0 или 2.2.

Ну вот, а речь идет о 2.4 и виртуялбокс, хота он основан на коде qemu...

> При fsync() никакого немедленного обращения к диску не происходит. Вего навсего, данные, находящиеся в страничном кэше, относящиеся к этому файлу, немедленно отправляются на уровень блочной подсистемы. Ни больше, ни меньше. А дальше, в каком порядке что записывать, решает планироващик ввода/вывода блочной подсистемы. И опять же, делается это отнюдь не немедленно. Обычно, величина таймаута для write запросов составляет порядка 5 ms.

> А дальше, в каком порядке что записывать, решает планироващик ввода/вывода блочной подсистемы.

Ага, так что у ребят в ядре есть на выбор 2 варианта:
1. отложить запись на по-дольше, и получить немеряные лаги в sqlite/firefox/whatever
2. сделать запись по-скорее, и получить срыв оптимизаций дискового IO

И вот они трахаются с этим tradeoff, хотя в 99% случаев fsync там нафиг не нужен.