C # создает столько экземпляров класса, сколько есть процессоров

Хотя исчерпывающий ответ на лучшие практики многопоточного развития немного превосходит то, что я могу здесь написать, пару вещей:

• Не используйте Sleep(), чтобы ждать, когда что-то продолжит, если АБСОЛЮТНО необходимо. Если у вас есть другой процесс кода, который вам нужно дождаться завершения, вы можете либо Join() использовать этот поток, либо использовать ManualResetEvent или AutoResetEvent. В MSDN есть много информации об их использовании. Потратьте некоторое время, чтобы прочитать его.
• Вы не можете гарантировать, что ваши потоки будут выполняться на своем ядре. Хотя вполне вероятно, что планировщик потоков ОС сделает это, просто имейте в виду, что он не гарантируется.

Да, имеет смысл то, что вы пытаетесь сделать.

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

Вы должны помнить, что вы можете обновлять GUI только из потока графического интерфейса. Это также может быть источником ваших проблем.

Невозможно сказать, в чем проблема, без дополнительной информации или примера кода.

Я бы предположил, что самый простой способ увеличить использование процессоров - это просто вызвать рабочие методы на потоках из ThreadPool (вызывая ThreadPool.QueueUserWorkItem). Если вы сделаете это в цикле, среда выполнения закроет потоки из пула потоков и параллельно будет запускать рабочие потоки.

ThreadPool.QueueUserWorkItem(state => DoWork());

Никогда не используйте Sleep для синхронизации потоков.

В вашем вопросе недостаточно подробностей, но вы можете использовать ManualResetEvent, чтобы заставить рабочих ждать первоначальный запрос.

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

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

Как упоминалось в другом месте, все это обрабатывается в основном потоке. Учитывая информацию, которую нужно обработать, мы подталкиваем ее к новому потоку (который для нас идет и извлекает 100 МБ данных и обрабатывает его за вызов). Такой подход позволил нам масштабироваться за пределы одного сервера. Раньше нам приходилось сталкиваться с высоким уровнем аппаратного обеспечения, и теперь мы можем бросить несколько более дешевых, но все же очень способных серверов. Мы также можем это сделать через нашу ферму виртуализации в периоды низкой загрузки.

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

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

Хорошо, нашел мой код MySql для того, чтобы делать то, что вам нужно.

    DELIMITER //

    CREATE PROCEDURE getnextid(
        I_service_entity_id INT(11)
      , OUT O_tag VARCHAR(36)
    )

    BEGIN
      DECLARE L_tag VARCHAR(36) DEFAULT '00000000-0000-0000-0000-000000000000';
      DECLARE L_locked INT DEFAULT 0;

      DECLARE C_next CURSOR FOR
        SELECT tag FROM workitems
        WHERE status in (0)
          AND processable_date <= DATE_ADD(NOW(), INTERVAL 5 MINUTE)
        ;

      DECLARE EXIT HANDLER FOR NOT FOUND
      BEGIN
        SET L_tag := '00000000-0000-0000-0000-000000000000';
        DO RELEASE_LOCK('myuniquelockis');
      END;

      SELECT COALESCE(GET_LOCK('myuniquelockis',20), 0) INTO L_locked;
      IF L_locked > 0 THEN
        OPEN C_next;
        FETCH C_next INTO I_tag;
        IF I_tag <> '00000000-0000-0000-0000-000000000000' THEN
          UPDATE workitems SET
              status = 1
            , service_entity_id = I_service_entity_id
            , date_locked = NOW()
          WHERE tag = I_tag;

        END IF;
        CLOSE C_next;
        DO RELEASE_LOCK('myuniquelockis');
      ELSE
        SET I_tag := L_tag;
      END IF;
    END
    //

    DELIMITER ;

В нашем случае мы возвращаем GUID в С# в качестве параметра out. Вы можете заменить SET в конце с помощью SELECT L_tag; и сделать с ним и потерять параметр OUT, но мы вызываем это из другой оболочки...

Надеюсь, что это поможет.

Вы также можете сделать блокировку кода "выборка из БД", таким образом, только один поток будет запрашивать базу данных за раз, но, очевидно, это несколько уменьшает прирост производительности.

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

Однако, предполагая, что вы извлекаете задачу из БД, и для этих задач требуется некоторое время на С#, вы, вероятно, захотите что-то вроде этого:

object myLock;

void StartWorking()
{
    myLock = new object(); // only new it once, could be done in your constructor too.
    for (int i = 0; i < Environment.Processorcount; i++)
    {
        ThreadPool.QueueUserWorkItem(null => DoWork());
    }
}

void DoWork(object state)
{
    object task;
    lock(myLock)
    {
        task = GetTaskFromDB();
    }

    PerformTask(task);
}

Кажется, вы сталкиваетесь с общей проблемой многопоточного программирования. Он назвал Race Condition, и вам следует сделать некоторые исследования по этой и другим проблемам многопоточности, прежде чем переходить слишком далеко. Очень легко быстро испортить все ваши данные.

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

Я не знаю MySQL. Хорошо, чтобы дать полный ответ, однако очень простой пример для T-SQL может выглядеть так:

BEGIN TRAN 
DECLARE @taskid int 
SELECT @taskid=taskid FROM tasks WHERE assigned = false
UPDATE tasks SET assigned=true WHERE taskid = @taskID 
SELECT * from tasks where taskid = @taskid 
COMMIT TRAN

MySQL 5 и выше поддержка транзакций тоже.

Я подозреваю, что у вас есть такая проблема: вам нужно сделать копию переменной цикла (задачи) в currenttask, иначе все потоки фактически будут иметь одну и ту же переменную.

<main thread>
var tasks = db.GetTasks();
foreach(var task in tasks) {
   var currenttask = task; 
   ThreadPool.QueueUserWorkItem(state => DoTask(currenttask));
   // or, new Thread(() => DoTask(currentTask)).Start()
   // ThreadPool.QueueUserWorkItem(state => DoTask(task)); this doesn't work!
}

Обратите внимание, что вы не должны Thread.Sleep() в основном потоке ждать завершения рабочих потоков. если вы используете threadpool, вы можете продолжать ставить в очередь рабочие элементы, если вы хотите дождаться завершения выполняемых задач, вы должны использовать что-то вроде AutoResetEvent, чтобы дождаться окончания потоков.