Здравствуйте, Teolog, Вы писали:


T>А так- пустить 100 групп потоков по 3 с рандомным слипом, если до финиша добралась хотя бы одна группа с неправильной последовательностью срабатывания, не

Выше сказали, что sleep это no hire. Просто это по сути вероятностный тест, ибо в нем заложена некая недетерминированность.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:



S>>>Синхронизация где, в тесте или в реализации объетка? В объекте по любому нужна, т.к. до окончания метода1 может начать
S>>>работу метод2 и поломать все инварианты.
S>>В объекте синхронизация нужна, я о том, что предложенный мной подход с потоками и Join-ами не выявит отсутствия синхронизации. Подход со слипами по несколько секунд — тоже. Тест, который потребует синхронизации, должен кэшировать состояние объекта, например, один поток в цикле пытается вызвать метод 2, но фейлится (видимо, ловит исключение) и продолжает цикл. Второй поток параллельно вызыват 1. При наличии синхронизации первый поток должен выйти из цикла после успешного вызова 2. Но этот подход хорош в теории, ведь методы объекта могут быть достаточно противные, что бы состояние объекта выпадало из кэша. Тогда и этот подход не потребует синхронизации.

S>Не понял зачем парится с кэшированием, если у нас есть lock?

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

S>А как на практике тестируют lock-free структуры данных и соотв. код?
Если честно, то не занимался разработками таких структур в промышленных масштабах, а те, что разрабатывал — исходил из того, что они построены на более простых примитивах со своими гарантиями, например, CAS-update. Оно работало и мои тесты походили на то, как если бы я использовал бы обычную структуру, обернутую локами.

S>Просто в данном случае, если ТС выбрал lock,
S>то про потоки можно забыть, т.е. просто тестировать соотв. состояние. А если volatile -- то
про volatile — отдельный разговор. Мы не знаем полных условий, могут ли методы выполняться повторно, например, можно ли 1 выполнять после 2. Не зная этого, сложно спрогнозировать, что именно будем писать в volatile. И очень может быть, что вызванные параллельно методы 1 и 2 приведут к непредсказуемому результату, т.е. можем стереть запись о вызове 2, а можем не стереть ее. От этого будет зависеть, пройдет ли 3. Я бы тут volatile-у не доверился. Но CAS-update выглядит убедительным.

Можно ли забывать про потоки, если автор выбрал lock... — здесь все просто. Нельзя. Автор реализации мог выбрать lock и забыть вставить его в каком-то месте, например, по невнимательности. Хороший тест тестирует реализацию, а не идею о реализации. Идея может быть хороша и давать гарантии, а код — не обязательно.

Здравствуйте, Sharov, Вы писали:

S>·>А кто тебе обещал очередность sleep-ов?
S>Формально -- никто, но с большой вероятность, тот что 1000мс спал проснется раньше, чем тот что 3000мс. Что и нужно.
Зачем писать код "с большой (с какой именно, кстати?) вероятностью", когда можно писать код со 100% вероятностью?
Ведь если билд падает с маленькой вероятностью, это создаёт большие проблемы. А ещё представь у тебя есть много таких тестов — и каждый из них падает пусть и с маленькой вероятностью...

S>>> Также не ясно как своп может что-то поломать в этом сценарии ?
S>·>Тред может просыпаться позднее указанного времени. И по большому счёту в любом порядке. Особенно, если ты уменьшишь в 100 раз.
S>Скорее всего они все проснутся позднее, т.е. будет сдвиг у всех.
Мамой клянёшься?

S>Я согласен, что идея так себе, но для наколенного теста сойдет. А для посерьезнее надо думать.
Да что тут думать? Тестовый код синхронизируются ровно теми же механизмами... Запускаешь три тестовых треда, которые ждут отлочиваешь их в нужном порядке.

Здравствуйте, ·, Вы писали:

·>Неужели действительно так _надо_ писать тест на наличие volatile?
в каких-то случаях надо, в каких-то — нет. Один написал volatile и не написал тест, второй увидел volatile и стер его. Тесты идут? Идут. "Я же говорил, что volatile не нужен!". И никто не хватится этой volatile, особенно, если проект большой.

·>Честно говоря, я себе слабо представяю как написать _надёжный_ тест, который тестирует что переменная помечена volatile.
А и не нужно писать тест о том, что переменная помечена. Тестировать надо контракт, а не реализацию. Вполне вероятно, что volatile поменяют на lock и тест должен работать.
Но да, соглашусь, нахождение гонок в реализации очень сложно, по сравнению с обычными юнитами. Потому, в большинстве случаев будет достаточно code review.

Здравствуйте, samius, Вы писали:

s> ·>Неужели действительно так _надо_ писать тест на наличие volatile?
s> в каких-то случаях надо, в каких-то — нет. Один написал volatile и не написал тест, второй увидел volatile и стер его. Тесты идут? Идут.
В этом и беда... Что очень тяжело добиться того, чтобы тесты таки перестали идти. Случайные sleep вообще никак не помогут, т.к. будут создавать membar и без volatile.

s> ·>Честно говоря, я себе слабо представяю как написать _надёжный_ тест, который тестирует что переменная помечена volatile.
s> А и не нужно писать тест о том, что переменная помечена. Тестировать надо контракт, а не реализацию. Вполне вероятно, что volatile поменяют на lock и тест должен работать.
Это понятно. Но во-первых, в сабже таки _юнит_ тесты, во-вторых, всё равно не ясно как контракт многопоточки тестировать надёжно.

s> достаточно code review.
+1

Здравствуйте, ·, Вы писали:

·>Здравствуйте, samius, Вы писали:

·>В этом и беда... Что очень тяжело добиться того, чтобы тесты таки перестали идти. Случайные sleep вообще никак не помогут, т.к. будут создавать membar и без volatile.
Вот поэтому я и предположил, что "протестируйте это" означает ни что инное, как последовательность вызовов. Но не тесты на гонки.

s>> А и не нужно писать тест о том, что переменная помечена. Тестировать надо контракт, а не реализацию. Вполне вероятно, что volatile поменяют на lock и тест должен работать.
·>Это понятно. Но во-первых, в сабже таки _юнит_ тесты, во-вторых, всё равно не ясно как контракт многопоточки тестировать надёжно.
Когда у меня потек гонками один виндовый проект, было все настолько неприятно (вешал проводник и даже местами винду), что я предпринял следующее:
обернул штатный Monitor своей утилиткой, которая опционально (в DEBUG, например) писала информацию в Thread.Context о том, что нечто залочено. Таким образом, я для одних интерфейсов мог проверять, что к ним обращается код не из под захвата, для других, что под захватом, стал иметь возможность в ратнайме проверять конкретные последовательности захватов и при обнаружении циклов, которые могли бы дать дедлоки, кидать исключение и писать в лог стеки участников цикла.

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

С Volatile и CASUpdate-ами все сложнее, т.е. не поддается инструментальной диагностике такого уровня.

Здравствуйте, samius, Вы писали:

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

Не понял мысль про реализацию -- тест должен тестировать реализацию. Вроде ниже, в самом конце, об этом и написано.
Т.е. почему тест должен работать, если мы подменили реализацию? Если суть теста именно в тестировании реализации?
Меняем реализацию, меняем тест. Иначе смысл в этом тесте?

S>Поэтому, если тест не демонстрирует нам, что для качественной реализации требуется синхронизация, значит этот тест не качественный, или, как минимум, не полный. Он удовлетворяет условию задачи "протестируйте это", подразумевая что в неверной последовательности методы нельзя вызвать/выполнить. Но мы-то понимаем, что без синхронизации реализация потечет при достаточной нагрузке, либо после кибернейтов/слипов, как упоминали выше.

Почему тест должен диктовать реализацию, если речь не о TDD? Почему вопрос о синхронизации должен диктоваться тестом?
Тест должен проверять качество синхронизации, а не ее отсутствие.

S>>Просто в данном случае, если ТС выбрал lock,
S>>то про потоки можно забыть, т.е. просто тестировать соотв. состояние. А если volatile -- то
S>про volatile — отдельный разговор. Мы не знаем полных условий, могут ли методы выполняться повторно, например, можно ли 1 выполнять после 2. Не зная этого, сложно спрогнозировать, что именно будем писать в volatile. И очень может быть, что вызванные параллельно методы 1 и 2 приведут к непредсказуемому результату, т.е. можем стереть запись о вызове 2, а можем не стереть ее. От этого будет зависеть, пройдет ли 3. Я бы тут volatile-у не доверился. Но CAS-update выглядит убедительным.

Может и стоит тестировать состояние, чтобы отфильтровать непредсказуемое состояние? Конкретно для данной задачи я не знаю, мало вводных.

S>Можно ли забывать про потоки, если автор выбрал lock... — здесь все просто. Нельзя. Автор реализации мог выбрать lock и забыть вставить его в каком-то месте, например, по невнимательности. Хороший тест тестирует реализацию, а не идею о реализации. Идея может быть хороша и давать гарантии, а код — не обязательно.

Это да, зависит от гранулярности. Речь идет об одной секции lock, которая хранит инф-ию о вызвавщей ф-ии или
что-то вроде этого.

Вообще, интересная задача. Я тут другую задачку придумал -- как убедиться, не имея исходников и не читая msdn,
что вставка\удаление в List<T> не потоко безопасна? Т.е. получить тест, который всегда бы падал или
проходил. Наверное, все же лучше падал -- т.е. либо исключение, либо неправильное кол-во элементов (сломали инвариант).
Т.е. если бы в эту коллекцию добавили синхронизацию, то тест упал бы.

Ничего лучше чем загрузить потоками со случайной вставкой и удалением я не придумал...

Здравствуйте, ·, Вы писали:

S>>Я согласен, что идея так себе, но для наколенного теста сойдет. А для посерьезнее надо думать.
·>Да что тут думать? Тестовый код синхронизируются ровно теми же механизмами... Запускаешь три тестовых треда, которые ждут отлочиваешь их в нужном порядке.

Потоки то зачем тогда, и чем время между отлочиваниями отличает от sleep? Разве что заранее известным порядком,
хотя тоже не факт.

·>За thread.sleep в авто-тестах я бы сразу no hire делал. Оно не только работает ужасно долго делая билд тормозным солидным, но и иногда ломается, когда вдруг где-то что-то засвопит при очередном тестовом прогоне и завалит билд.

Золотые слова, не мальчика но мужа.

К сожалению, за процессом найма автоматически уследить невозможно. Поэтому множество (боюсь что большинство) нанятых таки лепит sleep (и ладно бы только в тесты, так ведь и в код тоже — "избегают race conditions"). Но здесь, к счастью, уже есть решение — lint'ер, который бьет по рукам таких писателей.

И я было уже расслабился, думая "молодец, решил проблему", чтобы через пару месяцев обнаружить в, так сказать, tips & trick guidelines слова типа "поскольку sleep нельзя, делайте waitFor с тем же таймаутом, это линтер не поймает, но результат будет тот же".

Здравствуйте, ·, Вы писали:


·>

·>class
·>{ 
·>    volatile bool firstDone;


·>    void doFirst() {
·>        doFirstStuff();
·>        firstDone = true;
·>    }

·>    void doSecond() {
·>        if(!firstDone) throw new IllegalState();
·>        doSecondStuff();
·>    }
  
·>}
·>

Выглядит как так себе идея в контексте задачи. А если после if, но перед throw был вызван doFirst? Всё ж сломается

Здравствуйте, SkyDance, Вы писали:

SD>К сожалению, за процессом найма автоматически уследить невозможно. Поэтому множество (боюсь что большинство) нанятых таки лепит sleep (и ладно бы только в тесты, так ведь и в код тоже — "избегают race conditions"). Но здесь, к счастью, уже есть решение — lint'ер, который бьет по рукам таких писателей.

В тестах без sleep иногда просто никуда, т.к. или слишком дорого, или слишком криво. Если где-то запускается поток, который должен успеть стартануть и начать что-то обрабатывать, то либо sleep с вероятностью что упадёт, либо ради тестов протягивать какие-то интерфейсы, что не всегда возможно и/или разумно.

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

KP>В тестах без sleep иногда просто никуда, т.к. или слишком дорого, или слишком криво. Если где-то запускается поток, который должен успеть стартануть и начать что-то обрабатывать, то либо sleep с вероятностью что упадёт, либо ради тестов протягивать какие-то интерфейсы, что не всегда возможно и/или разумно.

Интерфейсы протягивать надо не ради тестов, а для observability/visibility. Чтобы потом, безо всяких тестов, просто знать, что тот самый поток просто еще не запустился, или уже запустился, но сдох на взлете, или подвис, или еще что-то с ним случилось.
Тесты просто кодифицируют это поведение. И вообще, если что-то нужно делать "для тестов", почти гарантированно это что-то нужно будет в какой-то еще момент, вне тестов.

KP>Для таких случаев в запускалках тестов есть атрибуты типа flaky. Удобно.

Это обычно делают в обратную сторону, CI постоянно гоняет stress run, и flaky тесты автоматически помечает, а также требует от автора теста исправить, под угрозой отказа от запуска этого теста в CI.

S>Выше сказали, что sleep это no hire. Просто это по сути вероятностный тест, ибо в нем заложена некая недетерминированность.
В том то и смысл что не-детерминированность, тогда есть некая вероятность что он все-же нащупает на какой-то итерации тайминг вызовов дающий неверный результат.
Детерминированный тест можно написать если четкая последовательность уже известна, и другой быть просто физически не может.
А тут оно и есть, произвольный вызов с трех разных потоков в произвольной последовательности с произвольным таймингом(хоть все одновременно). Если баг есть, когда нибудь оно словит.

Здравствуйте, SkyDance, Вы писали:

SD>Интерфейсы протягивать надо не ради тестов, а для observability/visibility. Чтобы потом, безо всяких тестов, просто знать, что тот самый поток просто еще не запустился, или уже запустился, но сдох на взлете, или подвис, или еще что-то с ним случилось.

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

SD>Тесты просто кодифицируют это поведение. И вообще, если что-то нужно делать "для тестов", почти гарантированно это что-то нужно будет в какой-то еще момент, вне тестов.
SD>Это обычно делают в обратную сторону, CI постоянно гоняет stress run, и flaky тесты автоматически помечает, а также требует от автора теста исправить, под угрозой отказа от запуска этого теста в CI.

Ты очень любишь обобщать и выдавать своё мнение за единственно правильное

Здравствуйте, kaa.python, Вы писали:

KP>Выглядит как так себе идея в контексте задачи. А если после if, но перед throw был вызван doFirst? Всё ж сломается
Ээ.. Суть в том, чтобы дождаться выхода из doFirst. Если doFirst вышел, то можно смело звать doSecond. Пока не вышел — нельзя. Или я не понял твоё возражение|вопрос.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>Не понял мысль про реализацию -- тест должен тестировать реализацию. Вроде ниже, в самом конце, об этом и написано.
S>Т.е. почему тест должен работать, если мы подменили реализацию? Если суть теста именно в тестировании реализации?
S>Меняем реализацию, меняем тест. Иначе смысл в этом тесте?
Смысл теста в том, что бы проверять потребительские качества кода, т.е. то, насколько он соответствует спецификации. А как именно выполнена реализация — не теста дело. Может быть там магия работает, главное, что бы поведение было ожидаемым. Да и способен ли тест отличить блокирующую реализацию от локфри, например? Если поведение ничем не отличается.

S>Почему тест должен диктовать реализацию, если речь не о TDD? Почему вопрос о синхронизации должен диктоваться тестом?
Тест должен проверять соответствие требованиям. Написанным, или подразумеваемым. И если мы считаем, что код должен быть потокобезопасным, то это заносится в требования и тест должен демонстрировать соответствие им. Но не наоборот, делаем код безопасным, т.к. тест показал необходимость. Можно и наоборот, но первичны требования, т.к. без требований нет смысла и в тесте на проверку этих требований.

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

S>Может и стоит тестировать состояние, чтобы отфильтровать непредсказуемое состояние? Конкретно для данной задачи я не знаю, мало вводных.
Это уже сильно зависит от реализации, которая зависит от требований, которых мы не знаем

S>Вообще, интересная задача. Я тут другую задачку придумал -- как убедиться, не имея исходников и не читая msdn,
S>что вставка\удаление в List<T> не потоко безопасна? Т.е. получить тест, который всегда бы падал или
S>проходил. Наверное, все же лучше падал -- т.е. либо исключение, либо неправильное кол-во элементов (сломали инвариант).
S>Т.е. если бы в эту коллекцию добавили синхронизацию, то тест упал бы.
Тут сложно то, что обнаружение потокоопасности носит вероятностный характер. Несложно написать тест, способный обнаружить гонку, сложно сделать его детерминированным за конечное время. И все равно можно будет влиять на тест окружением. Например, выполнение на однопоточной машине не даст результата.

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

Здравствуйте, Teolog, Вы писали:

T> Если баг есть, когда нибудь оно словит.

Представьте масштабы Амазона, там это когда-нибудь будет выстреливать кучу раз в день. Не вариант.

Юнит тесты не предназначены для борьбы с проблемами параллелизма. Если тебе предложили сделать именно это, то им надо обратно в школу, в первый класс.

Здравствуйте, samius, Вы писали:

S>>Почему тест должен диктовать реализацию, если речь не о TDD? Почему вопрос о синхронизации должен диктоваться тестом?
S>Тест должен проверять соответствие требованиям. Написанным, или подразумеваемым. И если мы считаем, что код должен быть потокобезопасным, то это заносится в требования и тест должен демонстрировать соответствие им. Но не наоборот, делаем код безопасным, т.к. тест показал необходимость. Можно и наоборот, но первичны требования, т.к. без требований нет смысла и в тесте на проверку этих требований.

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

S>>Может и стоит тестировать состояние, чтобы отфильтровать непредсказуемое состояние? Конкретно для данной задачи я не знаю, мало вводных.
S>Это уже сильно зависит от реализации, которая зависит от требований, которых мы не знаем

Ну да, все-таки хотелось бы от ТС услышать продолжение истории, что он ответил и как отреагировали собеседующие?

S>>Вообще, интересная задача. Я тут другую задачку придумал -- как убедиться, не имея исходников и не читая msdn,
S>>что вставка\удаление в List<T> не потоко безопасна? Т.е. получить тест, который всегда бы падал или
S>>проходил. Наверное, все же лучше падал -- т.е. либо исключение, либо неправильное кол-во элементов (сломали инвариант).
S>>Т.е. если бы в эту коллекцию добавили синхронизацию, то тест упал бы.
S>Тут сложно то, что обнаружение потокоопасности носит вероятностный характер. Несложно написать тест, способный обнаружить гонку, сложно сделать его детерминированным за конечное время. И все равно можно будет влиять на тест окружением. Например, выполнение на однопоточной машине не даст результата.

HT не поможет разве?

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

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

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>Тест должен проверят корректность реализации, иначе простой mock возвращающий корректный результат
S>тоже будет соотв. требованиям и т.п. Но только проку от этого теста? Т.е. все-таки нельзя отделить
S>тест от реализации, хоть связь и должна быть неявной, т.е. подразумеваться.
Разумеется, тест проверяет корректность реализации. Но делает он это, наблюдая поведение реализации, а не наличие полей или признаков мока. А если поведение достойной реализации не отличается от поведения мока, то может быть и не нужна она, реализация?

S>Ну да, все-таки хотелось бы от ТС услышать продолжение истории, что он ответил и как отреагировали собеседующие?

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

S>HT не поможет разве?
На сколько я понимаю, нет. Модель памяти дотнета требует писать данные сразу по месту, не кэшируя в регистрах. А кэши у логических ядер общие. Т.е. потокоНебезопасный код будет на HT работать корректно.

S>Т.е. я по-хорошему вообще не вижу, как тесты могут помочь в корректной реализации многопоточности.
S>Все носит вероятностный характер.
Помочь могут, просто надо переходить от абсолютных гарантий к вероятностным. Тест, который будет сообщать что за 10 минут(часов) насилия код не дал сбоя — вполне себе полезен.