Когда использовать пул потоков в C #? [закрыто]

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

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

Я обычно использую Пул потоков каждый раз, когда я должен просто сделать что-то на другом потоке и действительно не забочусь, когда он работает или заканчивается. Что-то как вход или возможно даже фон, загружающий файл (хотя существуют лучшие способы сделать тот асинхронный стиль). Я использую свой собственный поток, когда мне нужно больше управления. Также то, что я нашел, использует Ориентированную на многопотоковое исполнение очередь (взломайте свое собственное) сохранить "объекты команды" хорошо, когда у меня есть несколько команд, что я должен продолжить работать в> 1 поток. Таким образом, Вы были бы, может разделить XML-файл и поместить каждый элемент в очередь и затем иметь несколько потоков, работающих над выполнением некоторой обработки на этих элементах. Я записал такую очередь обратно путь в uni (VB.net!), что я преобразовал в C#. Я включал его ниже ни по какой конкретной причине (этот код мог бы содержать некоторые ошибки).

using System.Collections.Generic;
using System.Threading;

namespace ThreadSafeQueue {
    public class ThreadSafeQueue<T> {
        private Queue<T> _queue;

        public ThreadSafeQueue() {
            _queue = new Queue<T>();
        }

        public void EnqueueSafe(T item) {
            lock ( this ) {
                _queue.Enqueue(item);
                if ( _queue.Count >= 1 )
                    Monitor.Pulse(this);
            }
        }

        public T DequeueSafe() {
            lock ( this ) {
                while ( _queue.Count <= 0 )
                    Monitor.Wait(this);

                return this.DeEnqueueUnblock();

            }
        }

        private T DeEnqueueUnblock() {
            return _queue.Dequeue();
        }
    }
}

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

Пулы потоков являются большими, когда у Вас есть больше задач обработать, чем доступные потоки.

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

Выезд этот страница на MSDN: http://msdn.microsoft.com/en-us/library/3dasc8as (По сравнению с 80) .aspx

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

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

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

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

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

Мир Diablo делает правильное замечание также. Вращение распараллеливает, не свободно. Это занимает время, и они используют дополнительную память для своего стекового пространства. Пул потоков снова использует потоки для амортизации этой стоимости.

Примечание: Вы спросили об использовании потока пула потоков, чтобы загрузить данные или выполнить диск ввод-вывод. Вы не должны использовать поток пула потоков для этого (по причинам, которые я обрисовал в общих чертах выше). Вместо этого используйте асинхронный ввод-вывод (иначе методы BeginXX и EndXX). Для FileStream, который был бы BeginRead и EndRead. Для HttpWebRequest, который был бы BeginGetResponse и EndGetResponse. Они более сложны для использования, но они - надлежащий способ выполнить многопоточный ввод-вывод.

Вот хорошая сводка пула потоков в .NET: http://blogs.msdn.com/pedram/archive/2007/08/05/dedicated-thread-or-a-threadpool-thread.aspx

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

Я предложил бы, чтобы Вы использовали пул потоков в C# по тем же причинам как любой другой язык.

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

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

Иначе Вы тратите объем своего времени, создавая и уничтожая потоки вместо того, чтобы просто делать работу, которую они предназначаются, чтобы сделать.

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

В приложении, где Вы создаете много потоков, издержки создания потоков становятся существенными. Используя пул потоков создает потоки однажды и снова использует их, таким образом избегая создания потока наверху.

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

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

израсходование пула потоков может иметь тонкие эффекты - некоторые таймеры.NET используют потоки пула потоков и не будут стрелять, например.

Не забудьте исследовать фонового рабочего.

Я нахожу множество ситуаций, он дает мне то, что я хочу, без тяжелой работы.

Ура.

MVC - это блестящая новая бутылка для того же старого вина, которое представляет собой паутину и то, как она работает.

С другой стороны, вы можете, наконец, отойти от asp.net жизненного цикла viewstate & page, обратной связи, сумасшедших URL-адресов и т.д.

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

Обычно я рекомендую сначала ввести код в уровень контроллера модели и после завершения, а затем изменить пользовательский интерфейс на вид и использовать механизмы маршрутизации URL MVC. В качестве альтернативы вы можете использовать любой приличный модуль перезаписи URL и сначала опубликовать URL в стиле REST и переписать старый URL на новый URL, а затем медленно конвертировать разделы вашего приложения в MVC.

Я не уверен, какой язык сервера вы используете, но у меня был большой успех с whtmltopdf и wicked _ pdf для Ruby on Rails.

Мне хотелось, чтобы пул потоков распределял работу между ядрами с как можно меньшей задержкой, и это не обязательно было хорошо играть с другими приложениями. Я обнаружил, что производительность пула потоков .NET не так высока, как могла бы быть. Я знал, что хочу один поток на ядро, поэтому я написал свой собственный класс замены пула потоков. Код предоставляется в качестве ответа на другой вопрос StackOverflow здесь .

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