Телеграмм чат группы ProCxx страница 16042

подскажите. у меня есть thread, который в цикле while(true) в течение всей работы программы выполняет одни и те же действия. правильно ли я сделаю, если перед завершением работы программы просто вызову .detach() к нему и после завершения основного потока он сам "умрет". Не будет ли это неопределенным поведением?

источник

14:32пожаловаться #4

m

magras in pro.cxx

A V

подскажите. у меня есть thread, который в цикле while(true) в течение всей работы программы выполняет одни и те же действия. правильно ли я сделаю, если перед завершением работы программы просто вызову .detach() к нему и после завершения основного потока он сам "умрет". Не будет ли это неопределенным поведением?

Это точно не нормальное решение, но ссылку на стандарт не дам.

В 20ом стандарте добавили jthread. Помимо того, что он join'ит тред в деструкторе, он может передать в функцию stop_token который можно использовать чтобы корректно завершить функцию. До 20го стандарта не сложно реализовать подобный механизм самому. Можно даже сделать его совместимым по интерфейсу со stop_token.

П

подскажите. у меня есть thread, который в цикле while(true) в течение всей работы программы выполняет одни и те же действия. правильно ли я сделаю, если перед завершением работы программы просто вызову .detach() к нему и после завершения основного потока он сам "умрет". Не будет ли это неопределенным поведением?

Вообще не стоит так делать. К примеру, если это какой-нибудь логгер, то он может умереть во время сохранения очередной записи и она получится кусочная.

источник

14:47пожаловаться #6

П

Пашечка in pro.cxx

Опять же, вроде нет гарантий последовательности "умирания" тредов, поэтому, если это тред использует данные, очищенные мейн тредом, то всё, юб

источник

14:49пожаловаться #7

A

Andrew in pro.cxx

На SO (без пруфов) написано, что для объектов, аллоцированых на стеке такого треда нет гарантии вызова деструкторов при завершении приложения; думаю, последствия понятны. Правда, если это так, то не понимаю, когда вообще detach тогда можно безопасно использовать.

источник

14:52пожаловаться #8

AV

A V in pro.cxx

спасибо большое

источник

14:52пожаловаться #9

A

Andrew in pro.cxx

BTW, я правильно понимаю, что до jthread любой .join() надо вызывать под try-catch, потому что join есть, joinable есть, а способа сделать join-only-if-joinable нет никакого?

источник

15:07пожаловаться #10

VS

Vlad Serebrennikov in pro.cxx

A V

подскажите. у меня есть thread, который в цикле while(true) в течение всей работы программы выполняет одни и те же действия. правильно ли я сделаю, если перед завершением работы программы просто вызову .detach() к нему и после завершения основного потока он сам "умрет". Не будет ли это неопределенным поведением?

http://eel.is/c++draft/basic.exec#basic.start.main-4
да, для того, что лежит на стеке, деструкторы вызваны не будут, и никакого неопределенного поведения в этом действии нет, насколько я понимаю

источник

15:08пожаловаться #11

m

magras in pro.cxx

Andrew

BTW, я правильно понимаю, что до jthread любой .join() надо вызывать под try-catch, потому что join есть, joinable есть, а способа сделать join-only-if-joinable нет никакого?

А if (t.joinable()) { t.join(); } недостаточно?

источник

15:08пожаловаться #12

A

Andrew in pro.cxx

Vlad Serebrennikov

http://eel.is/c++draft/basic.exec#basic.start.main-4
да, для того, что лежит на стеке, деструкторы вызваны не будут, и никакого неопределенного поведения в этом действии нет, насколько я понимаю

Невызов деструктора при вызванном конструкторе может не быть UB? И я что-то не уверен, что там даже завершение вызова конструкторов гарантируется в таком случае.

источник

15:09пожаловаться #13

SS

Sergey Skvortsov in pro.cxx

Andrew

BTW, я правильно понимаю, что до jthread любой .join() надо вызывать под try-catch, потому что join есть, joinable есть, а способа сделать join-only-if-joinable нет никакого?

Ну тред, кажется, не может стать не joinable конкурентно с потоком, где пытаются сделать join()

источник

15:09пожаловаться #14

SS

Sergey Skvortsov in pro.cxx

Sergey Skvortsov

Ну тред, кажется, не может стать не joinable конкурентно с потоком, где пытаются сделать join()

То есть классической проверки
if (t.joinable()) { t.join(); }
, как выше показали, достаточно

источник

15:10пожаловаться #15

A

Andrew in pro.cxx

magras

А if (t.joinable()) { t.join(); } недостаточно?

Так ничто не мешает треду завершиться после проверки и до джойна. Тем более, что формально завершение кода функции, которую ты передал в тред это "неодновременные" операции.

источник

15:10пожаловаться #16

SS

Sergey Skvortsov in pro.cxx

Andrew

Так ничто не мешает треду завершиться после проверки и до джойна. Тем более, что формально завершение кода функции, которую ты передал в тред это "неодновременные" операции.

joinable не про это

источник

15:10пожаловаться #17

m

magras in pro.cxx

Andrew

Так ничто не мешает треду завершиться после проверки и до джойна. Тем более, что формально завершение кода функции, которую ты передал в тред это "неодновременные" операции.

Это не делает его не joinable.

источник

15:10пожаловаться #18

SS

Sergey Skvortsov in pro.cxx

A thread that has finished executing code, but has not yet been joined is still considered an active thread of execution and is therefore joinable.

источник

15:10пожаловаться #19

A

Andrew in pro.cxx

Sergey Skvortsov

Ну тред, кажется, не может стать не joinable конкурентно с потоком, где пытаются сделать join()

Не понял вот этого. Если я пишу код std::thread(callback_f).join(), то, если колобок придет пустым, кажется, ничто не мешает ему к моменту после старта, но перед джином завершиться.
Я не вижу пока способа синхронизировать вызовы joinable и join.

источник

15:12пожаловаться #20