set_value_at_thread_exit

Сегодня опять приезжали машины водоканала. Мощный старик в синей униформе втянул воздух правой ноздрей и точно определил характер утечки: "Канализация, ядрена вошь!". Разбежавшись, он бесстрашно рыбкой нырнул в темный квадрат подвала. Изумленно мявкнули кошки. Пал Михалыч шел по колено в ЖБО. Успешно отбившись от полчищ насекомых разводным ключом, он грозно посмотрел на толстую трубу. Если там и была протечка, то под его тяжелым взглядом предпочла забиться в самый дальний угол. "Гейзенбаг", - подумал Михалыч, - "трафикгенератор нужен, туды его в качель..."
Выбравшись из воняющей преисподней, он направился вверх по стояку, все такой же мощный, но чуть более ароматный. Я был, видимо, первый, кто случайно открыл дверь.
- По моему сигналу начинай гадить в ватерклозет субстанцией переменной консистенции, в бога мать... чем переменней, тем лучше", - дед в спецовке без предупреждения начал инструктаж и сурово посмотрел мне в глаза, полные ужаса и изумления.
- Я как-то не планировал, - попытался я ретироваться за дверь, - и не хочу вообще...
Незваный гость решительно поставил страшный и подозрительно мокрый сапог в дверной проем.
- Захачивай быстрее, люди вообще-то работают, свищ ищут! - дед за ворот рубашки притянул меня к себе. - Я там по трубе постучу, а ты уж тут наддай, сынок.
Сынок остался хоть и напуган осенним визитом, но недостаточно... и, как пить дать, несдобровать бы ему, если бы он вовремя не вспомнил про подозрительную субстанцию под названием std::promise. Там полно мутного кода переменной консистенции. Имеются, например, механизмы, которые привязываются к смерти потоков. Ведь теоретически есть крохотная вероятность гонки данных при использовании обычного метода set_value. Вот разбудим мы этим поток-получатель, как пойдет он обращаться к ресурсам в поток-исполнитель, а там может быть... все что угодно! Гонка данных может быть в завершающемся потоке, вот что.
И вот, чтоб исключить даже эту ничтожную двухпроцентную вероятность, комитет решил добавить механизм, позволяющий не трубить о готовности сразу, а подождать окончания потока-производителя.
Так в нашу жизнь и заодно в стандарт c++11 вошел метод std::promise::set_value_at_thread_exit.
Судя по названию, метод этот должен записывать значение в разделяемое состояние std::promise в момент завершения текущего потока. Однако в стандарте это не указано. Если случайно найти там раздел 33.10.5 Shared state [futures.state], то в пункте 10 будет указано:

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

Комитет с барского плеча даровал нам функцию, но не стал разъяснять, как именно вендоры должны её реализовать на уровне операционных систем. В результате бедолага стала одной из самых отстающих в реализации. Это забавно, но, например, Microsoft STL нагло нарушают стандарт! Ну, что вы из себя пионеров корчите?! Никогда стандарт не нарушали? Сейчас их set_value_at_thread_exit работает как обычный set_value. Он просто будит поток сразу. Micro-разработчики это признают, но честная реализация этого метода стоила бы поломанного ABI. Поэтому ждите следующей мажорной ветки разработки, а пока тикет Issue #3614 открыт.
Ну, чего удивляться, это же Микрософт. А что же GCC?