pthreads

ууу - срыды вообще говно
наверное ждет какого то события которое никогда не возникает
например ждет какую нить conditional variable а та функция которая
ее в true устанавливает выгружена.(функция из PIC модуля который был dlclosed)

Что значит засыпает? На чем засыпает на mutex? Тогда вопрос какой тип mutex, на condition variable ? Вопрос все тотже... В общем надо было бы немного поболее информации...

> ууу - срыды вообще говно

Ни хуя себе заявление. А обосновать?

2last anonymous:
щас срыды уже до тогого говна дошли что гораздо проще родить новый процесс нежели нить.
еще - если нить дохнет плохо то тянет(например в segmentation violation) то все подохнет.
а при fork() у тебя только этот процесс и здохнет.
по мне лучше использовать vfork в преforked енвироне.
Если Апликуха большая, модульная, со многими пересечениями - то процесс отладки будет занимать гораздо больше времени.

2lg: А, понятно, вы, юноша, просто их готовить не умеете :)

Я-то думал, по делу комментарии будут :)

anonymous (*) (2002-08-21 23:34:33.464):
> Я-то думал, по делу комментарии будут :)
В отличие от твоего, комментарии lg были, действительно, по делу.
А ежели ты так крут, то поведай, чем, кроме модного слова, треды могут
привлечь внимание разработчика? Траблы, вкраце и по делу, lg описАл.

Действительно, когда подох процесс это не так страшно как segfault в нити. Но, в сложных программах с множеством связий в многопроцессной моделе слишком много усилий тратится на организацию межпроцессного взаимодействия, в то время как в многопоточной таких проблем нет. Я для себя нашел оптимальное решение: я использую пулы потоков в сочетании с guardian'ом, который перезапускает процесс в случае segfault'а.

anonymous (*) (2002-08-22 04:30:24.873):
> в многопроцессной моделе слишком много усилий тратится на организацию
> межпроцессного взаимодействия,
Зато все явно, что написАл, то и получил. Мало того, на СМП машинках
(а только для них и имеют смысл треды!) минимизация использования шареной
памяти позволяет минимизировать потери на некогерентность кешей. А это
ДЕЙСТВИТЕЛЬНО проблема! На реальных задачах из-за нее невозможно получить
линейную масштабируемость по процессорам больше 3-4 (разумеется, во многих
тестах рекламного характера линейная масштабируемость достигает 64, но я -
про реальные задачи, а не про тесты).

> в то время как в многопоточной таких проблем нет.
Зато есть масса других, связанных с синхронизацией, IMHO значительно более
сложных. Аргумент-то приводился именно к стоимости РАЗРАБОТКИ, а не
эффективности!

> пулы потоков в сочетании с guardian'ом, который перезапускает процесс в
> вслучае segfault'а.
Весьма распространенное решение, BTW. Два "Но".

1. Не всегда просто безболезненно перезапустить процесс с любого места.
Как правило, реализация такой возможности приводит к большим накладным
расходам, связанным с журналированием, определением транзакций и т.п.
2. А кто будет перезапускать guardian'а вслучае segfault'а? - Я к тому,
что guardian все равно должен будет использовать какой-нибудь способ IPC,
помимо общетредной памяти.

Вообще, треды vs. процессы отзвучали 30 лет назад - в пользу изолированных
процессов. Но неуклюжесть win32 вновь возродила забытую дискуссию, но теперь
уже треды - модно и правильно.

По поводу кешей - да, это действительно большая проблема. Но объем данных, которыми надо обмениваться бывает очень значителен, и не всегда удобно использовать шареную память. Бывают и такие случаи, когда заранее нельзя предвидить, что стоит пихать в шареную память (расширяемые модульные системы). Пихать туда все подряд - авось пригодится кому-нибудь - это однозначно плохая идея. Синхронизация в многопоточных программах вовсе не так уж сложна.

За guardian'ом никто не следит. Предполагается что он настолько прост что в нем не бывает segfault'ов, и практика это подтверждает. Для его работы хватает самого примитивного IPC, а именно проверки кодов возврата дочерних процессов. Что касается корректного перезапуска, то все эти проблемы касаются и многопроцессной программы.

> Пихать туда все подряд - авось пригодится кому-нибудь - это однозначно плохая идея.
Тонко подмечено!

Поэтому-то нитки и не годятся, ибо это и есть "пихание всего подряд в шареную память".
Прикинь, пул ниток И ЕСТЬ совокупность независимых процессов, у которых ВСЯ
память расшарена! Использовать нитки И ЕСТЬ "Пихать туда все подряд - авось пригодится
кому-нибудь".

> Но объем данных, которыми надо обмениваться бывает очень значителен, и не всегда
> удобно использовать шареную память.
Однако, именно для обмена большими объемами шареную память обычно и используют!

Короче, в контексте многопроцессорных систем обычно противопоставляются
системы с общей памятью и cистемы с распределенной памятью. С первыми обычно
ассоциируются SMP и векторно - конвейерные системы, со вторыми - MPP и кластеры. Если
объемы передаваемых данных не особо велики, cистемы с распределенной памятью
предпочтительнее, ибо они более масштабируемы, и меньше проблем с когерентностью.
Но если данных много, или они плохо сериализуются, системы с общей памятью
обычно более производительны. При этом сериализация данных сама по себе не страшна,
обычно bottleneck'ом является именно скорость передачи в среде, ибо данные ВСЕГДА
можно сериализовать, просто иногда они при этом сильно размножатся.

В более узком смысле SMP cистемы часто понимаются как СИНОНИМ cистем с распределенной
памятью! И нитки - всего лишь самый тупой, прямолинейный и ненадежный алгоритм
реализации SMP.

>За guardian'ом никто не следит.... Для его работы хватает самого примитивного IPC, а
> именно проверки кодов возврата дочерних процессов.
Дык - это только в простейших случаях канает!


Вообще, сам факт необходимости guardian'а IMHO уже демонстрирует несамодостаточность
концепции тредов.