Поток, создающий BackgroundWorkers, кажется, ставит в очередь события Completed

РЕДАКТИРОВАТЬ: Хорошо, я начинаю с нуля. Вот короткое, но полное консольное приложение, в котором показана проблема. Он регистрирует время сообщения и ветку, в которой оно находится:

using System;
using System.Threading;
using System.ComponentModel;

class Test
{
    static void Main()
    {
        for(int i=0; i < 20; i++)
        {
            Log("Starting " + i);
            BackgroundWorker worker = new BackgroundWorker();
            worker.WorkerReportsProgress = true;
            worker.DoWork += DoWork;
            worker.RunWorkerCompleted += Completed;
            worker.ProgressChanged += Progress;
            worker.RunWorkerAsync(i);
        }
        Console.ReadLine();
    }

    static void Log(object o)
    {
        Console.WriteLine("{0:HH:mm:ss.fff} : {1} : {2}",
            DateTime.Now, Thread.CurrentThread.ManagedThreadId, o);
    }

    private static void Progress(object sender,
                                 ProgressChangedEventArgs args)
    {
        Log(args.UserState);
    }

    private static void Completed(object sender,
                                  RunWorkerCompletedEventArgs args)
    {
        Log(args.Result);
    }

    private static void DoWork(object sender, DoWorkEventArgs args)
    {
        BackgroundWorker worker = (BackgroundWorker) sender;
        Log("Worker " + args.Argument + " started");
        lock (typeof(Test)) // Ensure only a single request at a time
        {
            worker.ReportProgress(0, "Start");
            Thread.Sleep(2000); // Simulate waiting on the request
            worker.ReportProgress(50, "Middle");
            Thread.Sleep(2000); // Simulate handling the response
            worker.ReportProgress(100, "End");
            args.Result = args.Argument;
        }
    }
}

Пример вывода:

14:51:35.323 : 1 : Starting 0
14:51:35.328 : 1 : Starting 1
14:51:35.330 : 1 : Starting 2
14:51:35.330 : 3 : Worker 0 started
14:51:35.334 : 4 : Worker 1 started
14:51:35.332 : 1 : Starting 3
14:51:35.337 : 1 : Starting 4
14:51:35.339 : 1 : Starting 5
14:51:35.340 : 1 : Starting 6
14:51:35.342 : 1 : Starting 7
14:51:35.343 : 1 : Starting 8
14:51:35.345 : 1 : Starting 9
14:51:35.346 : 1 : Starting 10
14:51:35.350 : 1 : Starting 11
14:51:35.351 : 1 : Starting 12
14:51:35.353 : 1 : Starting 13
14:51:35.355 : 1 : Starting 14
14:51:35.356 : 1 : Starting 15
14:51:35.358 : 1 : Starting 16
14:51:35.359 : 1 : Starting 17
14:51:35.361 : 1 : Starting 18
14:51:35.363 : 1 : Starting 19
14:51:36.334 : 5 : Worker 2 started
14:51:36.834 : 6 : Start
14:51:36.835 : 6 : Worker 3 started
14:51:37.334 : 7 : Worker 4 started
14:51:37.834 : 8 : Worker 5 started
14:51:38.334 : 9 : Worker 6 started
14:51:38.836 : 10 : Worker 7 started
14:51:39.334 : 3 : Worker 8 started
14:51:39.335 : 11 : Worker 9 started
14:51:40.335 : 12 : Worker 10 started
14:51:41.335 : 13 : Worker 11 started
14:51:42.335 : 14 : Worker 12 started
14:51:43.334 : 4 : Worker 13 started
14:51:44.335 : 15 : Worker 14 started
14:51:45.336 : 16 : Worker 15 started
14:51:46.335 : 17 : Worker 16 started
14:51:47.334 : 5 : Worker 17 started
14:51:48.335 : 18 : Worker 18 started
14:51:49.335 : 19 : Worker 19 started
14:51:50.335 : 20 : Middle
14:51:50.336 : 20 : End
14:51:50.337 : 20 : Start
14:51:50.339 : 20 : 0
14:51:50.341 : 20 : Middle
14:51:50.343 : 20 : End
14:51:50.344 : 20 : 1
14:51:50.346 : 20 : Start
14:51:50.348 : 20 : Middle
14:51:50.349 : 20 : End
14:51:50.351 : 20 : 2
14:51:50.352 : 20 : Start
14:51:50.354 : 20 : Middle
14:51:51.334 : 6 : End
14:51:51.335 : 6 : Start
14:51:51.334 : 20 : 3
14:51:53.334 : 20 : Middle

(так далее)

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

РЕДАКТИРОВАТЬ: Дальнейшее исследование: если я позвоню ThreadPool.SetMinThreads(500, 500), то даже на моем компьютере с Vista он покажет, что все рабочие начинают работать в основном вместе.

Что произойдет с вашим ящиком, если вы попробуете указанную выше программу с вызовом SetMinThreads и без него? Если это поможет в этом случае, но не вашей реальной программе, не могли бы вы написать такую ​​же короткую, но полную программу, которая показывает, что проблема все еще остается проблемой даже с вызовом SetMinThreads?

Я верю, что понимаю это. Я думаю, что ReportProgress добавляет новую задачу ThreadPool для обработки сообщения... и в то же время вы заняты добавлением 20 задач в пул потоков. Что касается пула потоков, то в том, что если для обслуживания запроса, как только он поступает, недостаточно потоков, пул ждет полсекунды, прежде чем создать новый поток. Это делается для того, чтобы избежать создания огромной группы потоков для набора запросов, которые можно было бы легко обработать в одном потоке, если бы вы просто ждали завершения существующей задачи.

Итак, в течение 10 секунд вы просто добавляете задачи в длинную очередь и создаете новый поток каждые полсекунды. Все 20 «основных» задач относительно длинные, в то время как ReportProgress задач очень короткие, поэтому, как только у вас будет достаточно потоков для обработки всех длительных запросов и одного короткого, вы уйдете и все сообщения приходят быстро.

Если вы добавите вызов в

ThreadPool.SetMaxThreads(50, 50);

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

Один комментарий к вашему дизайну: у вас есть 20 разных задач в разных потоках, но только одна из них может выполняться одновременно (из-за блокировки). Вы в любом случае эффективно сериализуете запросы, так зачем использовать несколько потоков? Я надеюсь, что в вашем реальном приложении нет этой проблемы.

Класс BackgroundWorker выполнит свои обратные вызовы в потоке создания, это очень удобно для задач пользовательского интерфейса, поскольку вам не нужно выполнять дополнительную проверку InvokeRequired, за которой следует Invoke() или BeginInvoke().

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

Решение состоит в том, чтобы управлять своими потоками самостоятельно. Вы уже продемонстрировали, что знаете, как создать поток вручную, хотя, возможно, вы захотите просмотреть тему ThreadPool для получения дополнительной информации о том, как это сделать.

ОБНОВЛЕНИЕ: вот рабочий пример, основанный на отзывах, в котором используется Queue и пользовательский поток SingletonWorker.

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
        SingletonWorker.ProgressHandler = Progress;
        SingletonWorker.CompleteHandler = Completed;
    }
    private void button1_Click( object sender, EventArgs e )
    {
        // this is based on an app requirement, seems odd but I'm sure there's a reason :)
        Thread thread = new Thread( AddTasks );
        thread.Start();
    }
    private void AddTasks()
    {
        for ( int i = 0; i < 5; i++ )
        {
            AddToLog( "Creating Task " + i );
            SingletonWorker.AddTask( new Task { NumberToWorkOn = i } );
        }
    }
    private void AddToLog( string message )
    {
        if( textBox1.InvokeRequired )
        {
            textBox1.Invoke( new Action<string>( AddToLog ), message );
            return;
        }
        textBox1.Text += DateTime.Now + "   " + message + System.Environment.NewLine;
        textBox1.Select( textBox1.Text.Length, 0 );
        textBox1.ScrollToCaret();
    }
    private void Progress( string message, int percentComplete )
    {
        AddToLog( String.Format( "{0}%, {1}", percentComplete, message ) );
    }
    private void Completed( string message )
    {
        AddToLog( message );
    }
}
public class Task
{
    public int NumberToWorkOn { get; set; }
}
public static class SingletonWorker
{
    private static readonly Thread Worker;
    private static readonly Queue<Task> Tasks;
    // assume params are 'message' and 'percent complete'
    // also assume only one listener, otherwise use events
    public static Action<string, int> ProgressHandler;
    public static Action<string> CompleteHandler;
    static SingletonWorker()
    {
        Worker = new Thread( Start );
        Tasks = new Queue<Task>();
        Worker.Start();
    }
    private static Task GetNextTask()
    {
        lock( Tasks )
        {
            if ( Tasks.Count > 0 )
                return Tasks.Dequeue();

            return null;
        }
    }
    public static void AddTask( Task task )
    {
        lock( Tasks )
        {
            Tasks.Enqueue( task );
        }
    }
    private static void Start()
    {
        while( true )
        {
            Task task = GetNextTask();
            if( task == null )
            {
                // sleep for 500ms waiting for another item to be enqueued
                Thread.Sleep( 500 );
            }
            else
            {
                // work on it
                ProgressHandler( "Starting on " + task.NumberToWorkOn, 0 );
                Thread.Sleep( 1000 );
                ProgressHandler( "Almost done with " + task.NumberToWorkOn, 50 );
                Thread.Sleep( 1000 );
                CompleteHandler( "Finished with " + task.NumberToWorkOn );
            }
        }
    }
}

У меня была та же проблема: потоки BackgroundWorker запускались последовательно. Решение состояло в том, чтобы просто добавить следующую строку в мой код:

ThreadPool.SetMinThreads(100, 100);

Значение MinThreads по умолчанию равно 1, поэтому (возможно, в основном на одноядерном ЦП) планировщик потоков, вероятно, предположит, что 1 является приемлемым в качестве количества одновременных потоков, если вы используете BackgroundWorker или ThreadPool для создания потоков, поэтому потоки работают в серийная мода т.е. чтобы последующие запущенные потоки ждали завершения предыдущих. Заставляя его разрешить более высокий минимум, вы заставляете его запускать несколько потоков параллельно, т. Е. Разделяя время, если вы запускаете больше потоков, чем у вас есть ядер.

Это поведение не проявляется для класса Thread, т. е. thread.start(), который работает правильно одновременно, даже если вы не увеличиваете значения в SetMinThreads.

Если вы также обнаружите, что ваши вызовы к веб-службе работают максимум до 2 за раз, это связано с тем, что 2 является максимальным значением по умолчанию для вызовов веб-службы. Чтобы увеличить это, вы должны добавить следующий код в файл app.config:

<system.net>
  <connectionManagement>
    <add address="*" maxconnection="100" />
  </connectionManagement>
</system.net>