Есть некоторые ресурсы и их надо обработать в X потоков.
Как лучше организовать мультипоточность?

Создаем X потоков, в них цикл вечный. В цикле дергается 1 из ресурсов. Обрабатывается. Если ресурсов нет, то break.

Это очевидный способ. Есть ли что-то лучше? Я видел класс ThreadPool, но не очень понял, как его юзать и подойдет ли он.
Слушаю ваших советов.

по взаимодействию потоков много теории. Особенно по задачами синхронизации...так называемые гонки и тупики.  Посоветовать литературу не могу, бо сам изучал и делал в универе, у меня все в конспектах лежит.
поищите сперва инфу по этим темам, а уж как запустить Х потоков класса Thread проблем не будет

v_enom, в универе мало давали, максимум - это как избежать дэдлоков.

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

Это так в билдере на С++ называется метод, на # наверняка что-то подобное.
Почитай про Threads  у Шилда, например.
Многопоточность вообще не проблема. Валом теории на русском.

мне бы кто с WCF объяснил.... 

v_enom, не, я про это все знаю ) Юзаю крит. секции и мьютексы. Просто мне кажется, что неудачно юзаю ;)

Сколько потоков?

Alca, 200+.

http://forum.sources.ru/index.php?showtopic=271380

Это сообщение отредактировал(а) Alca - 9.11.2009, 18:17

Вы уверены, что Вам действительно необходимы 200+ потоков?
Имхо кол-во потоков должно быть равно числу процессоров, иначе ОС тратит больше времени на переключение между ними, чем на полезную работу.
Юзайте ThreadPool, либо обычные threads, но в количестве Environment.ProcessorCount.

Ram1reS, ну а как иначе распараллелить?)
200 процессов будут куда хуже, чем 200 потоков ;)
А с socket_select-подобными методами работы с сетью много гемора.

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

Было бы лучше ИМХО, перейти от абстракций к конкретике. А пока каждый из участников топика мирно рассуждает о своем ))
Для поддержки этого приятного диалога и я свои 5 копеек вставлю тогда...

nerezus, идея подписки на remote-события не рассматривалась? Я имею в виду ситуацию, когда не сервер трекает своих многосисленных клиентов, а просто подписывается на событие, публикуемое клиентом.

Клиент выбрасывает это событие в нужный момент и сервер подключается только к нему, не тратя время попусту на "пассивных" в данный момент клиентов.

Допустим есть сервис, и на него надо заданное количество N(много больше M) повзаимодействовать продолжительно(десятки запросов в обе стороны за 1 конект), в M потоков.

Вот такая задача.

nerezus, а теперь точно так-же, но только понятно  

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

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

Так что ...  говорить о том что создавать новый поток - накладно ... у меня уже и язык не поворачивается ))

Как-то эти накладные расходы меркнут по сравнению с расходами на коннекшены и интеракшены... Я бы тут о пуле коннекшенов думал, а не о пуле потоков )

По поводу потоков.... ИМХО, ThreadPool - юзать. В конечном счете в 99% случаях все к нему сводится. Как юзать - хорошо написано в msdn и у нашего незабвенного товарища Рихтера Джеффри.

 Ну я так не делаю, потоки создаются изначально и берут куски работы.
С другой стороны совсем не накладно, т.к. это лишь доли процента от работы потока.

 Ага вот ) Но так легче мне, сначала насоздавать и потом с ними работать, чтобы внутри каждого цикл куски работы брал в цикле.