nikitadanilov

            chunk_count = size / KHEAP_CHUNK_SIZE;
            if KHEAP_CHUNK_SIZE * chunk_count != size {
                chunk_count += 1;
            }

Можно

chunk_count = (size + KHEAP_CHUNK_SIZE - 1) / KHEAP_CHUNK_SIZE;

Какое отношение это имеет к доказательству корректности какой-либо конкретной программы?

Так оно и будет для однопоточных, детерминированных, нераспределенных (т.е. тривиальных) программ.

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

Если размер вектора равен числу процессов, то векторные часы точно отражают зависимости в системе.

> Несуществующие зависимости возникают потому, что логические часы вводят полный порядок на событиях

Показания векторных часов только частично упорядочены.

handle err {… } это возрожденный ON-unit из PL/I? Казалось бы отцы-основатели структурного программирования высмеяли такие штуки навсегда, но нет.

Статья (или перевод) вводит в заблуждение. Классический компьютер, т.е. (детерминированная) машина Тьюринга, может решить любую задачу решаемую квантовым компьютером. В cтатье (или опять же, в переводе) утеряна разница между «решаемо» и «эффективно решаемо», и между «computability» и «complexity».

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

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

«Сильный» программист, наверное, заметит, что команды X(номер, цвет) для разных значений параметра «номер» коммутативны (могут выполняться в произвольном порядке), а для одинаковых — нет. Это наблюдение сразу дает все три варианта A, B и C. Ну и по завету Дейкстры («детерминизм — частный случай недетерминизма»), напишет параллельную программу, для которой ABC являются сериализациями.

А почему pivot выбирается именно как элемент массива с некоторым индексом? В случае quicksort это понятно, но для quickselect можно выбрать любое значение (не обязательно из массива). Например, брать среднее (O(n)), тогда массив будет гарантированно хорошо делиться.

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

Mutex.Lock() гарантировано содержит атомарную операцию, т.е. cache transfer там точно будет.

Вывод show_sizeof() не соответствует коду: нет x.__class__.

В Ситибанке несколько лет назад для защиты от keylogger-ов пароль вводился через «виртуальную клавиатуру» (т.е. на сайте надо было мышкой кликать в нарисованные буковки), и на этой клавиатуре не было смены регистра. Клавиатура давно пропала, на пароли, ясно дело, остались с тех пор case insensitive.

Так как поддерживается восстановление 2 блоков на страйп, то, наверное, каждый страйп должен содержать 2 Empty блока?

Такие технологии становятся по-настоящему полезными только когда данные разнесены не только по устройствам на одной машине, но и по многим машинам в сети. Сетевой RAID сложно сделать на аппаратном уровне (как говорит raidixteam слишком гибкие конфигурации).

X | A | B = (!A | A) | (B | !B) | !C = true | true | !C = true

«в примарном разложении» — должно быть «в разложении на простые множители». «Примарное разложение» это немного другое (см. теорему Ласкера).

Ха, точно. Мир тесен.

Первое, что я сделал для Люстры был OSX клиент, но он так и не был выпущен, потому что Apple поменял VFS интерфейс в следующей версии Дарвина. Потом было много чего: новый сервер мета-данных (http://wiki.lustre.org/images/b/b8/LUG08-head-mds-danilov.pdf), новый клиентский IO стек (http://wiki.lustre.org/images/6/66/CLIO-TOI.pdf) и пр. Про новую систему (Mero) есть обзор: http://www.pdsw.org/pdsw-discs16/wips/danilov-wip-pdsw-discs16.pdf.

Я занимался Люстрой в 2004-2009, потом другой системой, для exascale.

Из упущенного: DAOS, http://storageconference.us/2015/Presentations/Gorda.pdf.

«Intel Infiniband»… Intel, конечно, всему голова, но стандарт просто Infiniband. :-)

Да, при прочих равных лучше в каноническом порядке отпускать локи. Меня просто смутила формулировка в статье. Статьи отличные, кстати. Спасибо.

Вы можете описать ситуацию, когда неправильный порядок *разблокировки*, т.е. отпускания мьютексов, приводит к проблемам? Ситуации, когда { unlock(A); unlock(B); } корректно, а { unlock(B); unlock(A); } ведет к deadlock-y?

> и, наконец, разблокируем все мьютексы в обратном порядке — справа налево. Не забываем, что основная причина deadlock – несоблюдение порядка блокировки/разблокировки нескольких мьютексов.

Разве порядок разблокировки может быть причиной deadlock? «Неправильная» разблокировка (слева направо, в данном случае) может привести к образованию конвоя или thundering herd, но никак не к deadlock-у.

> Вы, похоже, пытаетесь выкрутиться из ситуации, придираясь к слову «разыменование».
В моих комментариях, которые вам необходимо перечитать, с самого начала и неоднократно было указано, что я понимаю «разыменование», как применение unary operator *. Каким образом вы его понимаете — до сих пор непонятно.

> Но это не так важно, ибо соответствующий раздел — «informative», а не «normative».
Есть другие примеры undefined behaviour, которые авторы решили не включать в этот список, или это удивительное исключение?

> Речь в данном разговоре идет о формальной легальности конструкции (size_t)&(((s *)0)-›m)
Очень жаль, что вы все время об этом разговаривали, потому что я, как как и было написано в моем первом сообщении, говорю о том, что в этой конструкции нет разыменования (т.е. применения unary *), вне зависимости от того, легальна ли вся конструкция.

Например (приходится повторить), в конструкции A[B] есть разыменование, потому что стандарт явно определяет ее как (*(A+B)). Для конструкции A->B такого сведения нет. Вы, кажется, пользуетесь каким-то своим неформальным пониманием разыменования, не определив его явно.

> И этк конструкция — нелегальна, ибо содержит применение оператора -> к указателю, не являющемуся указателем на объект.
Вы можете процитировать соответствующий пункт из списка undefined behaviours в конце стандарта?

> Наоборот 6.5.3.2/1 это запрещает.
Где конкретно? Там явно написано «The operand of the unary & operator shall be [...] unary * operator» и никаких ограничений на аргумент * нет, т.е. явно разрешается &(*(X)) для произвольного X.

Что значит «предотвращает запрещенное разыменование»? Стандарт просто отмечает, примечанием, что результат &(*0) должен быть 0, там ничего не говорится ни про какую «аннигиляцию».

> Оператор -> — это разыменование указателя.
Смешались в кучу кони, люди. :-)

С точки зрения стандарта, -> это не разыменование, семантика -> описана специальным образом (6.5.2.3), но стандарт гарантирует, что при некоторых условиях (X)->Y эквивалентно (*(X)).Y (примечание 69).

С неформальной точки зрения, offsetof(A, B) это просто константа компиляции, и никакого разыменования, т.е. обращения к памяти, ее вычисление не требует.

> На такой платформе такая реализация offsetof работать не будет.
С этим никто не спорит, у offset() есть и гораздо менее экзотические проблемы. И также понятно, что традиционная реализация вызывает undefined behaviour. Но вовсе не из-за отсутствующего там разыменования, а потому, что семантика A->B стандартом не сводится к арифметике над указателями (в отличие от семантики A[B]).

Обычный offsetof() может привести к undefined behaviour, когда применяется как offsetof(struct foo, array[n]), где n — больше числа задекларированных элементов в поле-массиве. Типичная ситуация: массив нулевой длины в конце структуры, фактически память под массив выделяется при аллокации.

Во-первых, применять адресную арифметику к null pointer стандартом C явно разрешено (см. C99, 6.5.3.2, особенно примечание 74, где явно указано, что даже разыменование нулевого указателя бывает законно). Во-вторых «разыменование null pointer» это применение операции разыменования (unary * operator) к нулевому указателю, а в макросе offsetof() такая операция просто-напросто отсутствует: этот макрос ничего не разыменовывает.

> А между тем еще в Турбо Паскале была возможность вкладывать одни функции в другие.
Как уточнение: вложенные функции были в Паскале с самого начала и, вообще, присутствуют почти во всех языках, происходящих от Алгола-60, C здесь как-раз исключение.

> Однако, это является неопределенным поведением по стандарту Си (из-за разыменования нуля)
offsetof() NULL не разыменовывает, он выполняет арифметические операции над NULL-pointer, что совершенно законно.

Да, он его изобрел и использовал в компиляторе Алгола-60.

> Этот механизм в чем-то похож на уровень привилегий х86.
Этот массив дескрипторов называется Dijkstra display: http://cs-exhibitions.uni-klu.ac.at/index.php?id=4&uid=9.

> 'direction'(*расстояние с англ.)
«Направление».

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

Вы не могли бы пояснить, какие проблемы у Люстры в такой конфигурации?

На отсканированных листочках «программирования в машинных кодах, без ассемблера» не видно, там обычный ассемблер.

Кроме того, Алгол-68 (на котором приведен пример) и Алгол-60 это совершенно разные языки.

В BNF нужно заменить "," на "','".

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

Почтальон звонит (дважды). :-)