T2. Join();

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

T2. Join();

А как насчет ошибок? Что если задача генерирует исключение? Если задача генерирует исключение, и оно не обрабатывается в блоке catch, то вызывается метод std:: terminate(). А это обычно означает закрытие приложения, чего обычно мы очень сильно хотим избежать. std:: future может передать исключение в родительский/вызывающий поток; это одна из причин, почему мне нравится эта возможность. В противном случае, можно вернуть некоторый код ошибки.

Когда thread покидает область видимости приложение завершается вызовом метода std:: terminate(), если текущая задача еще не завершена. Очевидно, этого следует избегать.

Не существует возможности запросить поток завершить исполнение (например, потребовать его завершиться как можно быстрее и насколько возможно безопасно), или принудительно прервать его исполнение (т.е. убить его). Мы оставили следующие возможности для реализации такого поведения:

· Разработать собственный механизм кооперативный отмены исполнения (с помощью разделяемых данных, вызывающий поток может установить значение, которое будет прочитано вызываемым потоком для быстрого и безопасного завершения),

· С помощью «нативного подхода» (получив доступ к дескриптору операционной системы с помощью thread:: native_handle()),

· Завершить процесс (с помощью std:: quick_exit()),

· Завершить программу (с помощью std:: terminate()).

Это все, о чем смогли договориться члены комитета. В частности, представители POSIX были ярыми противниками любой формы «отмены исполнения», хотя многие модели ресурсов в С++ основаны на деструкторах. Не существует идеального решения для любой системы и для всех возможных приложений.

Главная проблема при использовании потоков заключается в гонках (data races); т.е. два потока исполняются в одном адресном пространстве и могут независимо обращаться к объекту таким образом, что это приведет к непредвиденным результатам. Если один (или оба) потока будут изменять данные объекта и другой (или оба) потока будут читать данные объекта, то произойдет «гонка» за то, какая из операций будет выполнена первой. Результаты могут быть не просто неопределены; они обычно совершенно непредсказуемы. Во избежание гонок С++11 предоставляет программисту некоторые правила/гарантии:

· Функции стандартной библиотеки не должны прямо или косвенно обращаться к объектам, доступным из других потоков, если только эти объекты прямо или косвенно не передаются через аргументы функций (включая this).

· Функции стандартной библиотеки не должны прямо или косвенно изменять объекты, доступные из других потоков, если только эти объекты прямо или косвенно не передаются через аргументы функции (включая this).

· Реализации стандартной библиотеки должны избегать гонок за разные элементы в одной последовательности, которые могут изменяться параллельно.

Параллельный доступ к потоку ввода-вывода (stream) объектов, буферизированному потоку объектов или потоку из стандартной библиотеки С может привести к гонкам, если не указано обратное. Так, не следует разделять доступ к потокам ввода-вывода между двумя потоками исполнения, пока вы каким-либо образом не контролируете к ним доступ.

· Контролировать доступ к данным с помощью взаимного исключения (mutual exclusion).

· Контролировать доступ к данным с помощью блокировок.

· Ожидать действия другой задачи с помощью условных переменных.

· Возвращать значение из потока с помощью future.