Корректно убить поток

@mat_for_c · Регистрация: 26.04.2013

Студворк — интернет-сервис помощи студентам

Пусть имеется поток thrdWork, который обрабатывает большие данные. В результате этой работы в памяти каждый раз сохраняются наиболее лучшие результаты. Т.к. эти результаты перезаписываются, то вывод их в файл возможен по окончанию обработки данных, что не реально долго (возможно и сутки, если не дольше). Поэтому я хочу выводить результаты по нажатию на клавишу (скажем мне будет достаточно того, что thrdWork уже нашел), но при этом дальнейшая обработка мне не нужна, т.е. поток нужно убить раньше времени. Я пришел к 2 решениям:

1 решение:

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
void Work()
{
   thread thrdWork(Processing);
   thrdWork.detach();
 
   char cmd;
 
   while (true) {
      cin >> cmd;
 
      if (cmd == 'd')
         // отладочная информация
         // сколько и с какими параметрами найдены
         writeDebugInfo();                
      else if (cmd == 'p') {
         writeBest();
         return;
      }
   }
}
 
 
//main
   thread thrd(Work);
   thrd.join();

и 2 способ:

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// main
 
   vector<thread> v_thrd;
   v_thread.push_back(thread(Processing)); // thrdWork
 
   char cmd;
 
   while (true) {
      cin >> cmd;
 
      if (cmd == 'd')
         // отладочная информация
         // сколько и с какими параметрами найдены
         writeDebugInfo();                
      else if (cmd == 'p') {
         writeBest();
         v_thrd.clear();
      }
   }

Какой метод более корректен или есть решение получше,

@nmcf · 21.10.2015, 10:12

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

@mat_for_c · 21.10.2015, 10:38 **[ТС]**

Сообщение от nmcf

может, и данные будут некорректные после этого

даже если они будут писаться в глобальные?

@nmcf · 21.10.2015, 11:06

Дело не в глобальности, а в целостности. Например, 2 переменные запишет, а третью не успеет - она будет старое значение содержать и т. п.

@mat_for_c · 21.10.2015, 11:12 **[ТС]**

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

@Renji · 21.10.2015, 11:32

Если под Линуксом, то там есть pthread_cancel, вызывающий процесс схожий с броском исключения из вызванной в потоке cancellation point функции (без cancellation point не заработает). Под gcc этот "процесс" вроде как в исключение и преобразуется. Но вообще изврат, так как по сути выходит что сишные функции начинают плеваться исключениями.

quwy · 21.10.2015, 11:34

Сообщение от mat_for_c

Тогда каждый раз буду опрашивать переменную, отвечающую за завершение потока.

Только не забудьте объявить ее как volatile.

@mat_for_c · 21.10.2015, 11:42 **[ТС]**

Сообщение от quwy

Только не забудьте объявить ее как volatile

Да, с эти я знаком уже

@hoggy · 21.10.2015, 20:05

никак.
единственный способ потоку корректно завершиться - умереть естественной смертью.

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

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

@Dmitriy_M · 22.10.2015, 16:33

Сообщение от quwy

Только не забудьте объявить ее как volatile.

Вы хотели сказать использовать атомики? Т.к. С++11 так не рекомендует делать.

quwy · 22.10.2015, 17:08

Сообщение от Dmitriy_M

Вы хотели сказать использовать атомики?

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

@Dmitriy_M · 22.10.2015, 17:20

Сообщение от quwy

рассинхронизации не произойдет.

Откуда такая уверенность?

quwy · 22.10.2015, 17:28

Сообщение от Dmitriy_M

Откуда такая уверенность?

Оттуда, что иной сценарий видится мне совершенно невозможным.

У вас есть другое мнение? Пожалуйста, высказывайтесь.

@Dmitriy_M · 22.10.2015, 17:44

При использовании volatile в многопоточной среде никто ничего не гарантирует.
Более подробно смотрите cv (const and volatile) type qualifiers,Concurrency: Atomic and volatile in C++11 memory model
То что вы говорите это хаки завязанные на реализацию bool, volatile в конкретных компиляторах на конкретных архитектурах.

quwy · 22.10.2015, 18:05

Сообщение от Dmitriy_M

То что вы говорите это хаки завязанные на реализацию bool, volatile в конкретных компиляторах на конкретных архитектурах.

Я сразу сказал, что это не по канонам, но мы вроде об конкретном языке говорим, а не философствуем на тему? Данное решение работает, и является надежным. Можно конечно вместо нормального BOOL написать свой, который будет хранить один бит информации в килобайтном объекте, изменять его в течении миллиона тактов процессора, допускать неопределенные состояния и делать прочие непотребства. Но раз речь об относительно низкоуровневом языке, то по-умолчанию подразумевается работа с базовыми типами данных. В любой из существующих архитектур биты под BOOL либо все равны нулю, либо не все равны нулю, неопределенных состояний нет, а volatile не дает компилятору так или иначе запихнуть переменную в контекст потока. В результате atomic тут не обязателен и при этом, в отличие от volatile, доступен не во всех компиляторах (это к вопросу о привязке к компилятору).

@Dmitriy_M · 22.10.2015, 18:20

Сообщение от quwy

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

Дайте источник. Вы еще не учитываете, что у каждого ядра есть свой кеш, а volatile не гарантирует защиты от кеширования.

Сообщение от quwy

доступен не во всех компиляторах

Это в каких еще компиляторах нет атомарных переменных?

quwy · 22.10.2015, 18:41

Сообщение от Dmitriy_M

Дайте источник.

Источник чего?

Сообщение от Dmitriy_M

Вы еще не учитываете, что у каждого ядра есть свой кеш, а volatile не гарантирует защиты от кеширования.

Кеш всех ядер всегда содержит актуальные данные. В противном случае постоянно наблюдались бы проблемы несогласованности состояний. Поток в любой момент может быть перемещен с одного ядра на другое (и это в реальных системах происходит достаточно часто). Представляете, что было бы, если бы такой поток начал читать данные из кеша одного ядра, а после перемещения продолжил бы читать более старую или более новую версию этих данных из кеша другого ядра? Согласованность данных в кешах строго обязательна для нормального функционирования системы.

Сообщение от Dmitriy_M

Это в каких еще компиляторах нет атомарных переменных?

В компиляторах для контроллеров, например.

@Dmitriy_M · 22.10.2015, 19:02

Сообщение от quwy

Источник чего?

Источник на который вы опираетесь. Алена в свое время так же указала, что использование volatile.

Сообщение от quwy

Кеш всех ядер всегда содержит актуальные данные.

Как же.

Сообщение от quwy

В противном случае постоянно наблюдались бы проблемы несогласованности состояний

А они и наблюдаются, если нет синхронизации.

Сообщение от quwy

В компиляторах для контроллеров, например.

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

quwy · 23.10.2015, 12:26

Сообщение от Dmitriy_M

Источник на который вы опираетесь.

Документация по языку. Данное ключевое слово отбивает компилятору охоту оптимизировать доступ к переменной, и если написано if(a), то это всегда будет cmp [00ABCDEFh], 0 и je (или аналогичный по смыслу код), без перемещения переменной в регистр, вырезания проверок и т.п.

Что касается алениной информации о возможной неатомарности BOOL, то это, не имеет ни малейшего значения. Будь запись хоть сто раз не атомарной, все равно момент, когда переменная из "ноль" превращается в "не ноль", атомарен по определению.

Сообщение от Dmitriy_M

А они и наблюдаются, если нет синхронизации.

О какой синхронизации речь? Я описал вам реальную ситуацию, когда даже однопотоковое приложение свалится, если кеши ядер не будут согласованы. Повторю еще раз: кеши ядер, которые кешируют пересекающиеся адреса, всегда согласованы, без этого система просто заглючит в первые же миллисекунды после запуска.

Сообщение от Dmitriy_M

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

Но не всегда это нужно.

@Avazart · 27.10.2015, 18:34

Сообщение от quwy

Я сразу сказал, что это не по канонам,

Это заведомо глупый совет, освежите знания!

См. Архитектура многопоточного приложения, Нужно ли синхронизировать доступ к переменной из двух потоков?

Кстати в boost есть interupt() для прерывания.

Новые блоги и статьи Все статьи Все блоги /
Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .
SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .	Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .

@nmcf 7804 / 6568 / 2988 Регистрация: 14.04.2014 Сообщений: 28,705
	21.10.2015, 10:12
	Никакой. Нельзя прерывать поток принудительно. Ты же не знаешь, на какой стадии он прервётся, может, и данные будут некорректные после этого. Используй средства синхронизации, чтобы поток сам завершался при определённых условиях. 0

@nmcf 7804 / 6568 / 2988 Регистрация: 14.04.2014 Сообщений: 28,705
	21.10.2015, 11:06
	Дело не в глобальности, а в целостности. Например, 2 переменные запишет, а третью не успеет - она будет старое значение содержать и т. п. 1

@mat_for_c 223 / 213 / 80 Регистрация: 26.04.2013 Сообщений: 972
	21.10.2015, 11:12 [ТС]
	Согласен. Тогда каждый раз буду опрашивать переменную, отвечающую за завершение потока. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	21.10.2015, 11:32
	Если под Линуксом, то там есть pthread_cancel, вызывающий процесс схожий с броском исключения из вызванной в потоке cancellation point функции (без cancellation point не заработает). Под gcc этот "процесс" вроде как в исключение и преобразуется. Но вообще изврат, так как по сути выходит что сишные функции начинают плеваться исключениями. 0

@hoggy 8973 / 4319 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	21.10.2015, 20:05
	никак. единственный способ потоку корректно завершиться - умереть естественной смертью. обычно делают так: потоки у себя в каком то цикле крутятся, и проверяют неккий атомарный флажок. если true, значит хотят закрыть лавочку снаружи. и поток корректно брякается из своей функции. 0

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	22.10.2015, 17:44
	При использовании volatile в многопоточной среде никто ничего не гарантирует. Более подробно смотрите cv (const and volatile) type qualifiers,Concurrency: Atomic and volatile in C++11 memory model То что вы говорите это хаки завязанные на реализацию bool, volatile в конкретных компиляторах на конкретных архитектурах. 0