Есть такой вот кусок кода, в котором в someFunc() делается произвольное количество (оценочно до 1000) паралельных вызовов аинхронного делегата MyDelegate(), определенного как MyFunc() в экземпляре класса WorkerClass.

    public delegate object MyDelegate();
    public class ThreadStarter
    {
        public MyDelegate Func { get; set; }
        public IAsyncResult Result { get; set; }
    }
    
    public class WorkerClass {
                public object MyFunc() {
                }
    }
    
    public class MainClass {
                List<ThreadStarter> _threads = new List<ThreadStarter>();
                
                private void someFunc(){
                        for (int i = 0; i< 10000; i++) {
                                ThreadStarter starter = new ThreadStarter();
                                Worker temp = new Reader();
                                starter.Func = temp.MyFunc();
                                starter.Result = starter.Func.BeginInvoke(null, null);
                                _threads.Add(starter);
            }
                }
                
                private void otherFunc(){
                        foreach (ThreadStarter thread in _threads){
                                object obj = thread.Func.EndInvoke(thread.Result);
                        }
                }
    }

Вопрос, не будет ли проблемы переполнения количества одновременных потоков? Вызов асинхронных делегатов как-то упорядочен в пул, или нужно продумать эту функциональность самому?

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


BeginInvoke использует ThreadPool. С одной стороны, большое число запросов — это грабли пула (разрулит складыванием потоков в очередь после превышения ThreadPool.GetMaxThreads). С другой, если вы поможете ThreadPool'у и ограничите свои запросы, ничего плохого не случится, даже наоборот, т.к. у пула останутся ресурсы для других задач.

Слегка непонятно, где выигрыш от такого распарралеливания...

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

S>BeginInvoke использует ThreadPool. С одной стороны, большое число запросов — это грабли пула (разрулит складыванием потоков в очередь после превышения ThreadPool.GetMaxThreads). С другой, если вы поможете ThreadPool'у и ограничите свои запросы, ничего плохого не случится, даже наоборот, т.к. у пула останутся ресурсы для других задач.
Супер! Спасибо!
S>Слегка непонятно, где выигрыш от такого распарралеливания...
Каждый поток читает и парсит свою web страницу, в то время как основной поток парсит основной набор страниц, собирая ссылки с них и отдавая в создаваемые потоки.

Здравствуйте, Interceptor.

I>Каждый поток читает и парсит свою web страницу, в то время как основной поток парсит основной набор страниц, собирая ссылки с них и отдавая в создаваемые потоки.

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

Как вариант можно приглядеться к Parallel Extensions или тупо разбивать список на сегменты и скармливать каждый отдельному потоку.

Да! не забывайте вызывать .EndInvoke()

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

S>Знаете, тут может оказаться эффективнее использовать свой пул — если хотите настраивать количество параллельных запросов и т.п., ThreadPool.SetMaxThreads — не самый лучший способ (особенно если планируется использовать асинхронные вызовы для чего-то кроме парсинга страниц).

В принципе, если допустимо unsafe, можно перепоручить это Completion Port. Он хорошо справляется с оптимизацией загрузки процессоров, а ThreadPool даёт к нему прямой доступ.