Пул задачи что такое

serg002 ★★★
05.10.23 01:58:41 MSK
Последнее исправление: serg002 05.10.23 02:20:20 MSK (всего исправлений: 1)

• Ответить на это сообщение
• Ссылка

Квалифицируешься в эффективного менеджера? О_о

Anoxemian ★★★★★
( 05.10.23 02:01:13 MSK )

• Ответить на это сообщение
• Ссылка

задача большая, она сегментируется на много подзадач?

Практически любая задача разбивается на подзадачи. А те которые казалось бы не разбиваются — все равно разбиваются в силу причин от тебя не зависящих: нужно есть, спать, ссать . ну ты понял.

задача тянется на несколько дней(по объективным причинам)

К примеру, задача должна выполняться неделю. Ты разбиваешь ее на части и пытаешься следовать плану на каждый день. Если закончил задачу раньше времени — берешь низкоприоритетную задачу из пула «хорошо было бы». Если не закончил за неделю — проводишь ретроспективу докапываясь до причин того, почему не вложился в график. Чаще всего проблема кроется в недостатке информации о задаче при планировании + не предусмотрел вероятность случайных событий по типу не успел на автобус, кошка начала рожать и т.д.

оставлять ли в пуле задач объемную задачу(прочитать книгу) или нет?

Тут все строится исходя из приоритета этой задачи. Если она тебя очень важна — ты должен запланировать и читать определенное количество глав каждый день.

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

Если эта задача для тебя важна и ты ее добавил в таск лист на каждый день и потом по какой-то причине удаляешь — ты изначально ошибся в планировании. Если у тебя часто возникают непредвиденные обстоятельства — предусмотри это в планировании. К примеру, ты примерно пытаешься читать по одной главе в день 7 дней в неделю. Тогда планируй не 7 глав прочитать в неделю а 6 или 5. Только гарантированно прочитать чтоб следовать плану.

как лучше работать с пулом задач? Общий пул задач или формировать цели из пула задач и в пул задач ставить цели?

Универсального рецепта нет и быть не может, так как все люди разные. Одни привыкли ставить задачи и четко им следовать. Другие — накидывать себе задачи каждый день из пула исходя из предполагаемого наличия на это времени, вдохновения и других факторов. Я для себя выбрал промежуточный вариант: есть пул задач и их приоритеты. Утром каждого дня примерно понятно сколько есть времени и подходящих условий для реализации той или иной задачи. Выбирается скойп задач с определенным приоритетом, с сортировкой от срочных до «хрен с ним, завтра сделаю».

В общем, как лучше и эффективней это всё формировать?

Если взять пример с книгой — то для начала нужно ответить себе на вопрос: нахрена тебе ее читать. Если джаст фо фан, то с 8ми (условно) часов времени 6-7 забивай делами и если все идет по плану — будет время почитать. Если нет — ну и хрен с ней.

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

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

iron ★★★★★
( 05.10.23 03:36:52 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile

Пул управляемых потоков

Класс System.Threading.ThreadPool обеспечивает приложение пулом рабочих потоков, управляемых системой, позволяя пользователю сосредоточиться на выполнении задач приложения, а не на управлении потоками. Если имеются небольшие задачи, которые требуют фоновой обработки, пул управляемых потоков — это самый простой способ воспользоваться преимуществами нескольких потоков. В Framework 4 и более поздних версиях использовать пул потоков стало значительно проще, так как вы можете создавать объекты Task и Task , которые выполняют в потоках пула асинхронные задачи.

Платформа .NET использует потоки из пула в различных целях, в том числе для операций библиотеки параллельных задач (TPL), асинхронного ввода-вывода, обратных вызовов таймера, регистрируемых операций ожидания, асинхронного вызова методов с использованием делегатов и для подключения к сокетам System.Net.

Характеристики пула потоков

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

Для каждого процесса существует только один пул потоков.

Исключения в потоках из пула потоков

Необработанные исключения в потоках из пула приводят к завершению процесса. Есть три исключения из этого правила:

• Исключение System.Threading.ThreadAbortException возникает в потоке пула вследствие вызова Thread.Abort.
• Исключение System.AppDomainUnloadedException возникает в потоке пула вследствие выгрузки домена приложения.
• Среда CLR или процесс ведущего приложения прерывает выполнение потока.

Максимальное число потоков в пуле потоков

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

Вы можете управлять максимальным количеством потоков с помощью методов ThreadPool.GetMaxThreads и ThreadPool.SetMaxThreads.

В коде, содержащем среду CLR, этот размер можно задать с помощью метода ICorThreadpool::CorSetMaxThreads .

Минимальные значения пула потоков

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

Если потребность низкая, фактическое количество потоков из пула потоков может быть ниже минимальных значений.

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

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

Использование пула потоков

Самым простым способом использования пула потоков является применение библиотеки параллельных задач (TPL). По умолчанию такие типы TPL, как Task и Task , используют потоки из пула для выполнения задач.

Пул потоков также можно использовать путем вызова ThreadPool.QueueUserWorkItem из управляемого кода (или ICorThreadpool::CorQueueUserWorkItem из неуправляемого кода) и передачи делегата System.Threading.WaitCallback, представляющего метод, который выполняет задачу.

Другим способом использования пула потоков является помещение в очередь рабочих элементов, которые имеют отношение к операции ожидания, с помощью метода ThreadPool.RegisterWaitForSingleObject и передача дескриптора System.Threading.WaitHandle, который вызывает метод, представленный делегатом System.Threading.WaitOrTimerCallback, при получении сигнала или истечении времени ожидания. Потоки из пула потоков используются для вызова методов обратного вызова.

Примеры см. по ссылкам на страницы API.

Пропуск проверок безопасности

Пул потоков также предоставляет методы ThreadPool.UnsafeQueueUserWorkItem и ThreadPool.UnsafeRegisterWaitForSingleObject. Используйте эти методы только в том случае, если вы уверены, что стек вызывающего объекта не важен для проверок безопасности, осуществляемых во время выполнения задачи в очереди. ThreadPool.QueueUserWorkItem и ThreadPool.RegisterWaitForSingleObject перехватывают стек вызывающего объекта, который объединяется со стеком потока из пула потоков, когда поток начинает выполнять задачу. Если требуется проверка безопасности, проверяется весь стек. Несмотря на обеспечение безопасности, такая проверка также влияет на производительность.

Когда не следует использовать потоки из пула потоков

Существует ряд сценариев, в которых следует создавать собственные потоки и работать с ними, а не использовать потоки из пула:

• Необходим основной поток.
• Поток должен иметь определенный приоритет.
• Имеются задачи, которые приводят к блокировке потока на длительное время. Для пула потоков определено максимальное количество потоков, поэтому большое число заблокированных потоков в пуле может препятствовать запуску задач.
• Необходимо поместить потоки в однопотоковое подразделение. Все потоки ThreadPool находятся в многопотоковом подразделении.
• Необходимо иметь постоянное удостоверение, сопоставленное с потоком, или назначить поток задаче.

См. также раздел

• System.Threading.ThreadPool
• System.Threading.Tasks.Task
• System.Threading.Tasks.Task
• Библиотека параллельных задач (TPL)
• Практическое руководство. Возвращение значения из задачи
• Объекты и функциональные возможности работы с потоками
• Потоки и работа с потоками
• Asynchronous File I/O
• Таймеры

Совместная работа с нами на GitHub

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