Зависание одного из потоков — это отнюдь не мелкая ошибка. В общем случае, ты не знаешь, что это за поток, для чего он предназначен, и в каком месте его логики произошло зависание. Кроме того, возможно причина зависания кроется совсем не в этом потоке, а в повреждении каких-то общих данных, некорректной логике других потоков и т.д. Для предотвращения описанной вами ситуации гораздо безопаснее использовать авто сохранение во временную папку, и после перезапуска предложить пользователю восстановить данные.
что делать, если поток блокирует ресурс на длительный период
Не блокировать общие ресурсы на длительное время. Серьёзно, это плохая практика, в не зависимости от того, как вы их затем собираетесь синхронизировать.
что за synh_
synh_ — экземпляр стратегии синхронизации, как правило один объект mutex и один объект condition.
В данном случае при любом раскладе программа становится неуправляемой и требуется перезапуск.
Но после выполнения половины действий поток А должен синхронизировать данные с потоком Б
Не совсем понял, что вы имеете ввиду. Есть общие ресурсы, в которые поток А произвёл запись, после чего освободил их. Поток Б, подождал, пока они освободятся и начал свой выполнение.
Я, в своё время, тоже об этом задумался, но потом решил что-всётаки это не правильно. Возможно источник ошибки в другом потоке, возможно он успел изменить какие-либо общие данные или залочить мьютексы и.т.д., кроме того, тогда все потоки изначально нужно проэктировать с учётом того, что их можно перезапустить. Коректно остановить поток по определению нельзя, так как он уже весит, можно только жёстко его убить, при этом не зная, что он делал в этот момент.
В одной системе, с которой я работал, применяли следующюю технику: Каждый поток приложения рапортовал, что он не завис, а отдельный специально созданный поток собирал рапорты, и осуществлял перезапуск системы, если от какого-то потока нет рапорта заданное время.
А если на это посмотреть с другой точки зрения? Человек должен расти порядка 14-16 лет, прежде чем он сможет взять в руки оружие, всё это время его нужно кормить, учить и обеспечивать безопасность.
Кроме того, даже если уничтожить источник материалов, уже наштампованные железки никуда не денутся.
Я и не говорил, что это задача простая, я говорил что она имеет решение( с точки зрения программиста ). Нужно единовременно вложить эндцать денег в разработку такой системы, после этого можно иметь сколько угодно таких войск в запасе, в не зависимости от количества населения. Так-же полностью теряется необходимость в срочной армии, так как залить софт в робота гораздо проще и быстрее, чем пол года муштровать призывника.
Возникает резонный вопрос — а зачем солдаты, если есть роботы?
Мне кажется уже сейчас возможно создать полностью автономного робота, который даст фору человеку. Всё-таки реакция робота и человека не сравнима, а при массовом использовании робот выйдет гораздо дешевле. Ну и кроме того: что хуже — потерять в ходе боевой операции бездушную железку или живого солдата?
Отличный подход.
Сам использую нечто подобное, только я пошёл несколько дальше и отказался от указателей и ссылок, используя вместо этого глобальный индексы. Унаследовав все классы моей иерархии от единого предка, который при создании регистрирует себя на фабрике индексов. Когда нужно обратится к какому-то объекту, то контейнер по индексу возвращает специальный временный объект, с перегруженным оператором ->. Кроме всех вышеперечисленных преимуществ, такая идеология позволяет избежать некорректного поведения при обращении к уже удалённому объекту и очень легко реализовать многопоточность.
Не блокировать общие ресурсы на длительное время. Серьёзно, это плохая практика, в не зависимости от того, как вы их затем собираетесь синхронизировать.
synh_ — экземпляр стратегии синхронизации, как правило один объект mutex и один объект condition.
В данном случае при любом раскладе программа становится неуправляемой и требуется перезапуск.
Не совсем понял, что вы имеете ввиду. Есть общие ресурсы, в которые поток А произвёл запись, после чего освободил их. Поток Б, подождал, пока они освободятся и начал свой выполнение.
ошибся ответом
Пробежался глазами — книга весьма интересная, почитаю на досуге.
int i = 5;
printf( "%d,%d", ++i, ++i );
Правильный ответ естественно undefined behavior.
Кроме того, даже если уничтожить источник материалов, уже наштампованные железки никуда не денутся.
Мне кажется уже сейчас возможно создать полностью автономного робота, который даст фору человеку. Всё-таки реакция робота и человека не сравнима, а при массовом использовании робот выйдет гораздо дешевле. Ну и кроме того: что хуже — потерять в ходе боевой операции бездушную железку или живого солдата?
Сам использую нечто подобное, только я пошёл несколько дальше и отказался от указателей и ссылок, используя вместо этого глобальный индексы. Унаследовав все классы моей иерархии от единого предка, который при создании регистрирует себя на фабрике индексов. Когда нужно обратится к какому-то объекту, то контейнер по индексу возвращает специальный временный объект, с перегруженным оператором ->. Кроме всех вышеперечисленных преимуществ, такая идеология позволяет избежать некорректного поведения при обращении к уже удалённому объекту и очень легко реализовать многопоточность.