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

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

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

K>>Но в отличии в случае многопоточности у нас вообще бесконечное число способов прийти в данное состояние, плюс любая операция записи может нафиг разрушить целостность памяти. И нет никакого способа проверить корректность.

_>Вот поэтому должны быть явно описаны требования, гарантии и инварианты. И желатьельно что бы их было мало и они были простые. Иначе будет бардак и "никакого способа проверить корректность".

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

З.Ы. Был как-то реальный случай, убрали одну ненужную строчку логирования, которая давно была в коде и всем мешала. Прогнали тесты все ок, да и какие проблемы может вызвать такое мелкое изменение. Но оказалось, что в коде много лет сидел race condition, эта никому не нужная запись в лог давала задержку в несколько микро или даже нано секунд, благодаря этому ошибка не проявлялась, а в продакшене вдруг стала периодически ни с того ни с сего вылезать.

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

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

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

K>>Но в отличии в случае многопоточности у нас вообще бесконечное число способов прийти в данное состояние, плюс любая операция записи может нафиг разрушить целостность памяти. И нет никакого способа проверить корректность.

_>Вот поэтому должны быть явно описаны требования, гарантии и инварианты. И желатьельно что бы их было мало и они были простые. Иначе будет бардак и "никакого способа проверить корректность".

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

З.Ы. Был как-то реальный случай, убрали одну ненужную строчку логирования, которая давно была в коде и всем мешала. Прогнали тесты все ок, да и какие проблемы может вызвать такое мелкое изменение. Но оказалось, что в коде много лет сидел race condition, эта никому не нужная запись в лог давала задержку в несколько микро или даже нано секунд, благодаря этому ошибка не проявлялась, а в продакшене вдруг стала периодически ни с того ни с сего вылезать. И это был код, который много лет проработал в продакшене, и был давно отлажен и протестирован.