И воспроизводится только на чужой машине, к которой нет прямого доступа
28.06.2019, 18:22
ну и пусть тогда секъюрити им код и правит
Для остальных. Race condition - состояние гонки. Состояние при котором результат выполнения криво написанного кода сильно зависит от того какой поток успеет быстрее что-то выполнить чем другой (возможно что-то другое). Что приводит к трудно выводимым багам, поскольку обычно всё работает, но иногда в силу того что планировщик задач раздал кванты времени как-то иначе, успевает то, что обычно не успевало и дальше мы ловим сегфолты, дедлоки, нулпоинтеры или неожиданные ошибки данных (возвращаются старые или даже испорченные данные).
Проблема в том, что в оригинальном сообщении автора выше нет ни слова про ядро, это раз. Никто не спорит что отладка в ядре накладывает серьезные ограничения и усложняет любую проблему.
Там, где в силу требований к производительности, нет нужды использовать опасные сложные lock/wait-free схемы, достаточно пользоваться написанными за тебя примитивами, критическими секциями и условными переменными и так далее. Отловить баги в таком радикально проще чем в lock/wait free схемах. Которые являются частным случаем ваших race conditions только намного более плохим, потому что они полагаются на то что автор учел все особенности работы компилятора, спекулятивного выполнения команд и алгоритмов когерентности l1 кэша используемой архитектуры/архитектур верно. Учитывая то, что проблемы в таком коде если он был первоначально отлажен проявляются очень редко и несистемно, а любой дебаг принт, сколь угодно быстрый на таких скоростях радикально меняет поведение кода и ошибка с вероятностью перестанет воспроизводиться... из методов отладки остается лишь медитация над кодом, эксперименты, гадания с целью локализовать дефектную часть и отчаянье. Это два.
Если знать про что есть последняя проблема из моего списка - там есть явное указание на то что это ядро. Это вызов функции, обработчика или ещё чего-то на уровне прерывания на котором оно не должно было быть вызвано. Как правило может вызваться почти чем угодно. От примитивной ошибки, где ты действительно вызвал функцию там где не следовало, до коррапта чужой памяти, который вызвал такой эффект неделю спустя или редкий дефект железа, который привел к последовательности действий которая обычно никогда не происходит и всё в таком духе. Метод отладки - от часов до недель которые придется искать зацепки в крэшдампе. Это три.
Наконец. Откуда такая непонятная заносчивость, и автоматическая постановка себя папой над другими? Непонятно.
Проблема в том, что в оригинальном сообщении автора выше нет ни слова про ядро, это раз. Никто не спорит что отладка в ядре накладывает серьезные ограничения и усложняет любую проблему.
Там, где в силу требований к производительности, нет нужды использовать опасные сложные lock/wait-free схемы, достаточно пользоваться написанными за тебя примитивами, критическими секциями и условными переменными и так далее. Отловить баги в таком радикально проще чем в lock/wait free схемах. Которые являются частным случаем ваших race conditions только намного более плохим, потому что они полагаются на то что автор учел все особенности работы компилятора, спекулятивного выполнения команд и алгоритмов когерентности l1 кэша используемой архитектуры/архитектур верно. Учитывая то, что проблемы в таком коде если он был первоначально отлажен проявляются очень редко и несистемно, а любой дебаг принт, сколь угодно быстрый на таких скоростях радикально меняет поведение кода и ошибка с вероятностью перестанет воспроизводиться... из методов отладки остается лишь медитация над кодом, эксперименты, гадания с целью локализовать дефектную часть и отчаянье. Это два.
Если знать про что есть последняя проблема из моего списка - там есть явное указание на то что это ядро. Это вызов функции, обработчика или ещё чего-то на уровне прерывания на котором оно не должно было быть вызвано. Как правило может вызваться почти чем угодно. От примитивной ошибки, где ты действительно вызвал функцию там где не следовало, до коррапта чужой памяти, который вызвал такой эффект неделю спустя или редкий дефект железа, который привел к последовательности действий которая обычно никогда не происходит и всё в таком духе. Метод отладки - от часов до недель которые придется искать зацепки в крэшдампе. Это три.
Наконец. Откуда такая непонятная заносчивость, и автоматическая постановка себя папой над другими? Непонятно.
два года, имхо, еще норм
все равно за 2 года (а может и раньше) проект зачастую надоедает, "приедается" и начинается болото и рутина
а вот если 2 месяца - вот это попоболь заметней
только нормально вкатились, команда притерлась с большего, процесс наладили - и хуй тебе, Марио, твоя принцесса в другом замке, начинай заново
все равно за 2 года (а может и раньше) проект зачастую надоедает, "приедается" и начинается болото и рутина
а вот если 2 месяца - вот это попоболь заметней
только нормально вкатились, команда притерлась с большего, процесс наладили - и хуй тебе, Марио, твоя принцесса в другом замке, начинай заново
таааккк - Буфера!!!!
А теперь представьте, что все вышеперечисленные проблемы разработчик умудрился поиметь кодя в JS
Аниме?
