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

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

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

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

1 решение:

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

C++

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++

// 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() для прерывания.

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

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

@mat_for_c 223 / 213 / 80 Регистрация: 26.04.2013 Сообщений: 972
	21.10.2015, 10:38 [ТС]	3
	Сообщение от nmcf может, и данные будут некорректные после этого даже если они будут писаться в глобальные? 0

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

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

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

quwy Native x86 5514 / 3273 / 934 Регистрация: 13.02.2013 Сообщений: 10,425
	21.10.2015, 11:34	7
	Сообщение от mat_for_c Тогда каждый раз буду опрашивать переменную, отвечающую за завершение потока. Только не забудьте объявить ее как volatile. 0

@mat_for_c 223 / 213 / 80 Регистрация: 26.04.2013 Сообщений: 972
	21.10.2015, 11:42 [ТС]	8
	Сообщение от quwy Только не забудьте объявить ее как volatile Да, с эти я знаком уже 0

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

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	22.10.2015, 16:33	10
	Сообщение от quwy Только не забудьте объявить ее как volatile. Вы хотели сказать использовать атомики? Т.к. С++11 так не рекомендует делать. 0

quwy Native x86 5514 / 3273 / 934 Регистрация: 13.02.2013 Сообщений: 10,425
	22.10.2015, 17:08	11
	Сообщение от Dmitriy_M Вы хотели сказать использовать атомики? Достаточно переменной. Это не совсем по канонам, но если булевую переменную изменяет только один поток, то кто и как бы не читал ее, рассинхронизации не произойдет. Самое худшее что может произойти -- ожидающий сигнала поток провернет один лишний цикл вместо того, чтобы завершиться немедленно. Но это только в том случае, если запись значения в эту переменную по каким-то невероятным причинам окажется не атомарной. 0

	27.10.2015, 18:34

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	22.10.2015, 17:20	12
	Сообщение от quwy рассинхронизации не произойдет. Откуда такая уверенность? 0

quwy Native x86 5514 / 3273 / 934 Регистрация: 13.02.2013 Сообщений: 10,425
	22.10.2015, 17:28	13
	Сообщение от Dmitriy_M Откуда такая уверенность? Оттуда, что иной сценарий видится мне совершенно невозможным. У вас есть другое мнение? Пожалуйста, высказывайтесь. 0

quwy Native x86 5514 / 3273 / 934 Регистрация: 13.02.2013 Сообщений: 10,425
	22.10.2015, 18:05	15
	Сообщение от Dmitriy_M То что вы говорите это хаки завязанные на реализацию bool, volatile в конкретных компиляторах на конкретных архитектурах. Я сразу сказал, что это не по канонам, но мы вроде об конкретном языке говорим, а не философствуем на тему? Данное решение работает, и является надежным. Можно конечно вместо нормального BOOL написать свой, который будет хранить один бит информации в килобайтном объекте, изменять его в течении миллиона тактов процессора, допускать неопределенные состояния и делать прочие непотребства. Но раз речь об относительно низкоуровневом языке, то по-умолчанию подразумевается работа с базовыми типами данных. В любой из существующих архитектур биты под BOOL либо все равны нулю, либо не все равны нулю, неопределенных состояний нет, а volatile не дает компилятору так или иначе запихнуть переменную в контекст потока. В результате atomic тут не обязателен и при этом, в отличие от volatile, доступен не во всех компиляторах (это к вопросу о привязке к компилятору). 0

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	22.10.2015, 18:20	16
	Сообщение от quwy volatile не дает компилятору так или иначе запихнуть переменную в контекст потока. Дайте источник. Вы еще не учитываете, что у каждого ядра есть свой кеш, а volatile не гарантирует защиты от кеширования. Сообщение от quwy доступен не во всех компиляторах Это в каких еще компиляторах нет атомарных переменных? 0

quwy Native x86 5514 / 3273 / 934 Регистрация: 13.02.2013 Сообщений: 10,425
	22.10.2015, 18:41	17
	Сообщение от Dmitriy_M Дайте источник. Источник чего? Сообщение от Dmitriy_M Вы еще не учитываете, что у каждого ядра есть свой кеш, а volatile не гарантирует защиты от кеширования. Кеш всех ядер всегда содержит актуальные данные. В противном случае постоянно наблюдались бы проблемы несогласованности состояний. Поток в любой момент может быть перемещен с одного ядра на другое (и это в реальных системах происходит достаточно часто). Представляете, что было бы, если бы такой поток начал читать данные из кеша одного ядра, а после перемещения продолжил бы читать более старую или более новую версию этих данных из кеша другого ядра? Согласованность данных в кешах строго обязательна для нормального функционирования системы. Сообщение от Dmitriy_M Это в каких еще компиляторах нет атомарных переменных? В компиляторах для контроллеров, например. 0

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	22.10.2015, 19:02	18
	Сообщение от quwy Источник чего? Источник на который вы опираетесь. Алена в свое время так же указала, что использование volatile. Сообщение от quwy Кеш всех ядер всегда содержит актуальные данные. Как же. Сообщение от quwy В противном случае постоянно наблюдались бы проблемы несогласованности состояний А они и наблюдаются, если нет синхронизации. Сообщение от quwy В компиляторах для контроллеров, например. Атомики как правило реализуются в виде библиотеки, и сделать свой класс атомиков для контроллера не так уж и сложно. 0

quwy Native x86 5514 / 3273 / 934 Регистрация: 13.02.2013 Сообщений: 10,425
	23.10.2015, 12:26	19
	Сообщение от Dmitriy_M Источник на который вы опираетесь. Документация по языку. Данное ключевое слово отбивает компилятору охоту оптимизировать доступ к переменной, и если написано if(a), то это всегда будет cmp [00ABCDEFh], 0 и je (или аналогичный по смыслу код), без перемещения переменной в регистр, вырезания проверок и т.п. Что касается алениной информации о возможной неатомарности BOOL, то это, не имеет ни малейшего значения. Будь запись хоть сто раз не атомарной, все равно момент, когда переменная из "ноль" превращается в "не ноль", атомарен по определению. Сообщение от Dmitriy_M А они и наблюдаются, если нет синхронизации. О какой синхронизации речь? Я описал вам реальную ситуацию, когда даже однопотоковое приложение свалится, если кеши ядер не будут согласованы. Повторю еще раз: кеши ядер, которые кешируют пересекающиеся адреса, всегда согласованы, без этого система просто заглючит в первые же миллисекунды после запуска. Сообщение от Dmitriy_M Атомики как правило реализуются в виде библиотеки, и сделать свой класс атомиков для контроллера не так уж и сложно. Но не всегда это нужно. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	27.10.2015, 18:34	20
	Сообщение от quwy Я сразу сказал, что это не по канонам, Это заведомо глупый совет, освежите знания! См. Архитектура многопоточного приложения, Нужно ли синхронизировать доступ к переменной из двух потоков? Кстати в boost есть interupt() для прерывания. 0