Каковы ограничения MS Concurrency Runtime?
Я использую простую параллельную среду выполнения task_group в Visual Studio 2010 для запуска одного рабочего потока, чтобы отделить работу от потока графического интерфейса.
Однако один из моих коллег сказал мне, что я неправильно использую CR: он был разработан для распараллеливания легких задач с небольшим контекстом, а не для отделения громоздких и зависимых от ввода / вывода потоков от GUI. Он сказал, что взял это из документации, но не предоставил никаких конкретных ссылок.
Так, Каковы ограничения Microsoft Concurrency Runtime и для решения каких проблем я НЕ должен его использовать?
Конечно, CR не является переносимым, но давайте оставим это без внимания: я говорю о ситуациях, когда вы кодируете компиляцию, но тем не менее у вас возникают проблемы.
Решение
Среда выполнения параллелизма — это инфраструктура совместного планирования. Если вы не собираетесь использовать преимущества совместного планирования, то вам лучше создавать потоки, когда это необходимо, и позволить ОС позаботиться о планировании.
если ты являются что касается совместного планирования, то в действительности нет никакого смысла ждать завершения операции ввода-вывода, поскольку вы блокируете поток, который в противном случае мог бы использоваться для выполнения других задач, которые не зависят от завершения этой операции ввода-вывода. Если другие задачи зависят от выполнения задачи ввода-вывода, вы можете просто сделать их продолжениями, и планировщик ConcRT обязательно выполнит их, когда придет их время.
Так что здесь дело не в ограничениях. Это просто знание того, чего вы пытаетесь достичь, и выбор правильного инструмента для работы.
Другие решения
Как упоминал Yam, среда выполнения параллелизма не обеспечивает гарантию параллельного выполнения, она просто создает потенциальную возможность, и в этом разница между понятиями задач и потоков. Если вы правильно выполнили свои задачи (не слишком гранулированные, чтобы тратить много времени на переключение между задачами, и не слишком грубые, чтобы всегда иметь какую-то работу для всех ядер — в вашем случае — только одного), тогда издержки не будут значительными, и Ваша программа будет готова для работы на многоядерной или многопроцессорной платформе, «будущая перспектива», как любят говорить MSFT.