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

BZ>потоки должны быть изолированы по данным. в true FP языках с их once-assign это решается автоматически, в других — при минимальных усилиях со стороны программиста
BZ>...
BZ>при неструктурированном убийстве и автоматическом переключении потоков первая проблема — возвращение памяти, принадлежащей переменным внутри этого потока. её можно решить, используя GC. вторая — неконсистентность разделяемых данных, её можно решить, используя в убиваемых потоках только message passing, и оставляя использование разделяемых данных на долю структурированно завершаемых потоков

Всё правильно, я тоже за категорический отказ от многопоточности. Позволю себе повториться:

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

Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.

http://rsdn.ru/forum/flame.comp/6064110.1

Автор: Философ
Дата: 31.05.15

Ты здесь предлагаешь почти тоже самое, ибо вынесение всей конкуренции в один поток — фактический отказ от многопоточности. Может лучше вообще не заморачиваться, а?

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

BZ>потоки должны быть изолированы по данным. в true FP языках с их once-assign это решается автоматически, в других — при минимальных усилиях со стороны программиста
BZ>...
BZ>при неструктурированном убийстве и автоматическом переключении потоков первая проблема — возвращение памяти, принадлежащей переменным внутри этого потока. её можно решить, используя GC. вторая — неконсистентность разделяемых данных, её можно решить, используя в убиваемых потоках только message passing, и оставляя использование разделяемых данных на долю структурированно завершаемых потоков

Всё правильно, я тоже за категорический отказ от многопоточности. Позволю себе повториться:

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

Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.

http://rsdn.ru/forum/flame.comp/6064110.1

Автор: Философ
Дата: 31.05.15

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

Понимаешь, если совсем нет связи по данным, то незачем связываться с многопоточностью: вполне можно обойтись многопроцессностью, а для надёжности код на разных машинах выполнять.