Здравствуйте, Mamut, Вы писали:

M>Что такое управлять потоками?

M>Все просто. Мы запустили поток, нам нужно:
M>- Знать, что поток выполняется
M>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой)
M>- Возможно, перезапустить поток, если он завершился
M>- Убить поток, если это необходимо

Зачем всё это? (зачем управлять потоками)
Почему нельзя положиться на рантайм — пусть он управляет. Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.

Что за глупость убивать поток?
Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток?


M>Что такое общаться друг с другом?

M>Все просто. Часто одному потоку надо знать о промежуточном состоянии другого потока или передать в другой поток какое-то свое промежуточное состояние. Как простейшие примеры:
M>- UI поток должен узнать, что что-то изменилось в долгоиграющем потоке, чтобы обновить свое состояние (прогрессбар, например)
M>- Долгоиграющий поток должен узнать, что что-то изменилось в окружающем мире, чтобы продолжить работу (появились новые данные, изменилась конфигурация и т.п.)

Не вижу здесь никакой проблемы: пусть UI узнает. Надо чтоб узнал — сообщи ему об этом, или пусть сам спросит, только не у потока, а у объекта, который ему предоставит Task<T>.Result .
Долгоиграющий поток????
Зачем такое что он делает: ждёт всю дорогу или что-то делает? Если он чего-то ждёт всю дорогу — то чего-нибудь дождётся, если что-то делает, то обрывать его плохая идея — пусть делает, и когда будет готов, то сам проверит.


M>

M>There is no portable way in C++11 (that I'm aware of) to non-cooperatively kill a single thread in a multi-thread program (i.e. without killing all threads).

И слава богу!
Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.

M>Потому что даже фраза «потоки могут общаться друг с другом» являются китайской грамотой для языков, в которых while(shared_variable != true) execute() является единственным способом общения между потоками

Я, кстати, тоже не совсем понимаю что такое общение между потоками. Пояснишь?
Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.



M>Механизмы и инструменты которые Erlang предоставляет из коробки, выросли напрямую из необходимости соответствовать этим требованиям. По некоторым пунктам:
M>1. Требует возможность создать множество параллельных процессов, которыми надо управлять, и которым надо общаться между собой.
M>2. Требует гарантий на время отклика системы
M>3. Требует механизмов для распределения системы по нескольким компьютером, что тянет за собой множество требований. Например, если умерла система X, система Y должна иметь возможность гарантированно об этом узнать
M>5. Нужны из коробки механизмы управления крупными системами (в случае с Эрлангом — управления множеством процессов)
M>8. Нужно иметь возможность обновить систему, не останавливая ее, что тянет за собой множество требований: как заставить долгоживушие процессы обновить код, что делать со stale code в памяти, как производить апгрейд структур в памяти и т.п.
M>10. В частности: если процесс умирает, он не должен утянуть за собой всю систему. Если процесс умер на машине X, об этом надо гарантированно узнать на машине Y и т.п.

Ты заешь что такое PAGE_FAULT?
Это то, от чего ты не можешь избавиться и то, что лишает тебя любых гарантий на время отклика системы.
В связи с этим, расскажи мне, как Erlang это гарантирует — не верю.

По остальным пунктам тоже комментарии не помешали бы.