2012-03-16 4 views
0

В документации указано иное («Делегатор тела вызывается один раз для каждого значения в диапазоне итераций»).Может Parallel.For Выполнить одно и то же действие (один и тот же указатель) более одного раза?

Однако мы наблюдали поведение, которое было бы объяснено, если одно и то же действие выполнялось более или менее одновременно разными потоками.

Я спрашиваю про самую простую перегрузку: Parallel.For(Int32, Int32, Action<Int32>).

+0

Вам будет лучше искать проблемы в своем собственном коде, а не надеяться, что TPL будет сломан. Не похоже, что это функциональность края в TPL, это очень мейнстрим. Какое еще может быть объяснение наблюдаемого поведения? Добавьте код отладки в делегат, если на вас ничего не выйдет. –

+0

@Steve, при всем уважении, это был не TPL, который, как я думал, может быть «сломан», но документация. Есть несколько мест в .NET, где данный делегат может быть вызван параллельно (_e.g._, гонка для инициализации). Да, это Funcs not Actions, но раньше я был удивлен .NET. Никакого вреда в спросе (или так я думал). –

+0

@WillMontgomery, TPL спроектирован таким образом, чтобы избежать проблем с потоками, таких как условия гонки. Это не значит, что вам не нужно быть осторожным с вашим собственным кодом, но это означает, что вы можете зависеть от того, что функции библиотеки ведут себя так, как вы ожидали. – svick

ответ

1

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

+0

Parallel.For не вызывал действие более одного раза; вместо этого Parallel.For вызывается параллельно с ним из-за плохого объявления объекта блокировки (local/instance, когда он должен быть глобальным/статическим). Таким образом, одно и то же действие _was_ фактически выполняется более или менее одновременно разными потоками. К сожалению, отчет о проблеме предполагал, что ошибка проявилась в одном экземпляре объекта, когда действительно это произошло в другом экземпляре (оба были получены из одного базового типа, поэтому оба метода имели тот же метод, что и Parallel.For). В любом случае, спасибо. –