N'Parallèle.ForEach Bloc?
Ne l' .net fonction En parallèle.ForEach bloquer le thread appelant? Je suppose que le comportement est l'un de ces:
- Oui, il bloque jusqu'à ce que le plus lent du point de l'exécution de retours.
- Non, il ne bloque pas et retourne le contrôle immédiatement. Les éléments à exécuter en parallèle sont effectuées sur les threads d'arrière-plan.
Ou peut-être quelque chose d'autre se passe, quelqu'un sait pour sûr?
Cette question s'est posée lors de la mise en œuvre de cette dans une classe de log:
public class MultipleLoggingService : LoggingServiceBase
{
private readonly List<LoggingServiceBase> loggingServices;
public MultipleLoggingService(List<LoggingServiceBase> loggingServices)
{
this.loggingServices = loggingServices;
LogLevelChanged += OnLogLevelChanged;
}
private void OnLogLevelChanged(object sender, LogLevelChangedArgs args)
{
loggingServices.ForEach(l => l.LogLevel = LogLevel);
}
public override LogMessageResponse LogMessage(LogMessageRequest request)
{
if (request.LogMessage)
Parallel.ForEach(loggingServices, l => l.LogMessage(request));
return new LogMessageResponse{MessageLogged = request.LogMessage};
}
}
Avis de la LogMessage
les appels de méthode de certains autres services de journalisation. J'ai besoin de cette partie de retourner immédiatement, afin de ne pas bloquer le thread appelant.
Mise à jour: Basé sur les commentaires des autres (nous avons confirmé le comportement est #1). Donc, j'ai pris des conseils pour utiliser le Tâche bibliothèque et réécrit la boucle comme ceci:
if (request.LogMessage)
foreach (var loggingService in loggingServices)
Task.Factory.StartNew(() => loggingService.LogMessage(request));
Vous devez vous connecter pour publier un commentaire.
Numéro 1 est correct;
Parallel.ForEach
ne pas revenir jusqu'à ce que la boucle est terminée. Si vous ne voulez pas que votre comportement, vous pouvez simplement exécuter votre boucle comme unTask
et l'exécuter sur un autre thread.Re votre mise à jour, StartNew normale dans un foreach() :
Cela peut ne pas être la plus optimale pour les grandes collections, et vous n'avez pas de point pour gérer les erreurs.
Votre loggingServices n'a probablement pas tenir des milliers d'articles, mais le errorhandling reste un point .
Considérer: