Pull or not Pull? What is a question.

На тему навел System.Threading.Timer - использую для фонового потока. Время от времени проводит операции по "зачистке" данных.
Так вот, Timer при срабатывании берет поток из пула и в нем что-то там делает.
С другой стороны, для обработки события я организую новый поток

Thread t1;
t1 = new Thread(Delegat);
t1.Start();

Но событие, само по себе, подобно Timer, сдается (по крайней мере нигде это явно не написано, или не увидел, что это написано) уже берет поток из пула. Получается только для того, чтобы запустить новый поток t1.
И почему бы не использовать для выполнения программы сразу поток из пула. - экономия очевидна, в т.ч. во времени.
С другой стороны t1 (созданный нами поток) легко контролируется-управляется, а из пула д.б.для этого дополнительные усилия.
Вот на выходных чешу репу - что использовать, и в каких случаях что лучше применять.
В общем вопрос философский, и существенно не влияет, но интересен сам по себе.


"Есть многое на свете, друг Горацио, что и не сразу в голову придет."
М. Твен "Приключения Геккельбери Финна"

YUBA, У thread pool два плюса:
1) thread pool позволяет съэкономить время на создание потока. Может оказаться важным если постоянно создаем много потоков.
2) thread pool ограничивает кол-во одновременно работающих потоков чтобы не перегружать систему.

Есть и минус - потоки в пуле являются background потоками, а значит их выполнение может быть прервано ОС когда в приложении не осталось ни одного foreground потока.

Поэтому если приложение создает много потоков и их принудительное завершение не яаляется проблемой, то thread pool хороший выбор.

YUBA
Но событие, само по себе, подобно Timer, сдается (по крайней мере нигде это явно не написано, или не увидел, что это написано) уже берет поток из пула.

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

bazile, Да, действительно, совсем упустил из виду. - В описании какого-то приложения читал, что обработчики событий должны быть как можно более короткими, т.к. обработка перехваченных событий происходит непосредственно в потоке приложения.
Т.е., да, не всегда событие порождает новый поток, например, при работе с DLL приложения.
Понятно, что в подобных случаях надо быстренько схватить и убежать. Но куда, в Пул или создать поток?

bazile
Есть и минус - потоки в пуле являются background потоками, а значит их выполнение может быть прервано ОС когда в приложении не осталось ни одного foreground потока. Поэтому если приложение создает много потоков и их принудительное завершение не яаляется проблемой, то thread pool хороший выбор.

Здесь что-то не понял.

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

В общем случае это не так. Скорость обработки и потоки никак не связаны. В отдельных случаях (например Timer) время работы обработчика может иметь значение. В большинстве случаев это не так. Как иначе мы бы смогли бы писать сложные и длинные обработчики для различных UI событий?

YUBA
Здесь что-то не понял.

Потоки делятся на две группы - foreground и background. Главный поток приложения и потоки создаваемые вручную по умолчанию является foreground потоками. Потоки в thread pool и TPL являются background потоками. Приложение завершает свою работу после завершения последнего foreground потока. При этом background потоки, если они есть, принудительно завершаются.

Вот пример. Попробуй запускать второй поток как background и как foreground чтобы увидеть разницу.

Action<string> printMsg100times = (string msg) => { for (int i = 0; i < 100; i++) Console.WriteLine("[{0:00}] {1}!", i, msg); };

			var mythread = new Thread(() => printMsg100times("Дополнительный поток"));
			mythread.IsBackground = true;
			mythread.Start();

			printMsg100times("Главный (UI) поток");

bazile
Вот пример. Попробуй запускать второй поток как background и как foreground чтобы увидеть разницу.

Изменил i< 5000 и даже i< 10000.
Ответ по быстродействию неоднозначен. На 10000 "Дополнительный поток", в смысле быстродействия, даже интересней.
Странно. Удивило.

Интересно, что раз на раз не приходится. То так то этак, и существенная разница.
Т.е., однозначности нет.

YUBA, дело не в быстродействии, а в том что второй поток может не успеть выполниться до конца когда он background. Разные результаты тоже легко объяснимы. Время исполнения потока контролируется ОС. Она же решает в каком порядке предоставлять процессор разным потокам. Мы можем частично на это влиять меняя приоритет потоков, но а целом контроль в руках ОС. Например, у меня в данный момент выполняется 67 процессов с примерно 960 потоков. Процессор двухядерный с HT. Значит паралельно могут выполняться только 4 потока. Остальные ждут своей очереди.