Meilleures pratiques en général du runtime d'accès concurrentiel

Ce document décrit les meilleures pratiques à appliquer à plusieurs zones du runtime d'accès concurrentiel.

Sections

Ce document contient les sections suivantes :

• Utiliser les éléments de synchronisation coopérative, dans la mesure du possible

• Éviter les tâches longues qui ne cèdent pas

• Utiliser le surabonnement pour compenser les opérations qui effectuent un blocage ou qui présentent une latence élevée

• Utiliser les fonctions de gestion de la mémoire simultanée, dans la mesure du possible

• Utiliser RAII pour gérer la durée de vie des objets d'accès concurrentiel

• Ne pas créer d'objets d'accès concurrentiel au niveau de la portée globale

• Ne pas utiliser d'objets d'accès concurrentiel dans les segments de données partagées

Utiliser les éléments de synchronisation coopérative, dans la mesure du possible

Le runtime d'accès concurrentiel fournit un grand nombre d'éléments sécurisés du point de vue de l'accès concurrentiel qui ne requièrent pas d'objet de synchronisation externe. Par exemple, la classe Concurrency::concurrent_vector permet d'effecteur des opérations d'ajout et d'accès aux éléments sécurisées du point de vue de l'accès concurrentiel. Toutefois, lorsque vous avez besoin d'un accès exclusif à une ressource, le runtime fournit les classes Concurrency::critical_section, Concurrency::reader_writer_lock et Concurrency::event. Ces types se comportent de manière coopérative. Par conséquent, le planificateur de tâches peut réallouer les ressources de traitement à un autre contexte pendant que la première tâche attend des données. Si possible, utilisez ces types de synchronisation au lieu d'autres mécanismes de synchronisation, tels que ceux fournis par l'API Windows, qui ne se comportent pas de manière coopérative. Pour plus d'informations sur ces types de synchronisation et pour obtenir un exemple de code, consultez Structures de données de synchronisation et Comparaison de structures de données de synchronisation avec l'API Windows.

[retour en haut]

Éviter les tâches longues qui ne cèdent pas

Étant donné que le planificateur de tâches se comporte de manière coopérative, il ne traite pas équitablement les tâches. Par conséquent, une tâche peut empêcher le démarrage d'autres tâches. Dans certains cas, c'est acceptable. Dans d'autres cas, cela peut provoquer un interblocage ou la privation.

L'exemple suivant effectue plus de tâches que le nombre de ressources de traitement allouées. La première tâche ne cède pas au planificateur de tâches. Par conséquent, la deuxième tâche ne démarre pas tant que la première n'est pas terminée.

// cooperative-tasks.cpp
// compile with: /EHsc
#include <ppl.h>
#include <iostream>
#include <sstream>

using namespace Concurrency;
using namespace std;

// Data that the application passes to lightweight tasks.
struct task_data_t
{
   int id;  // a unique task identifier.
   event e; // signals that the task has finished.
};

// A lightweight task that performs a lengthy operation.
void task(void* data)
{   
   task_data_t* task_data = reinterpret_cast<task_data_t*>(data);

   // Create a large loop that occasionally prints a value to the console.
   int i;
   for (i = 0; i < 1000000000; ++i)
   {
      if (i > 0 && (i % 250000000) == 0)
      {
         wstringstream ss;
         ss << task_data->id << L": " << i << endl;
         wcout << ss.str();
      }
   }
   wstringstream ss;
   ss << task_data->id << L": " << i << endl;
   wcout << ss.str();

   // Signal to the caller that the thread is finished.
   task_data->e.set();
}

int wmain()
{
   // For illustration, limit the number of concurrent 
   // tasks to one.
   Scheduler::SetDefaultSchedulerPolicy(SchedulerPolicy(2, 
      MinConcurrency, 1, MaxConcurrency, 1));

   // Schedule two tasks.

   task_data_t t1;
   t1.id = 0;
   CurrentScheduler::ScheduleTask(task, &t1);

   task_data_t t2;
   t2.id = 1;
   CurrentScheduler::ScheduleTask(task, &t2);

   // Wait for the tasks to finish.

   t1.e.wait();
   t2.e.wait();
}

Cet exemple produit la sortie suivante :

1: 250000000
1: 500000000
1: 750000000
1: 1000000000
2: 250000000
2: 500000000
2: 750000000
2: 1000000000

Il existe plusieurs façons d'activer la coopération entre les deux tâches. L'une des méthodes consiste à céder occasionnellement au planificateur de tâches lorsqu'une tâche met du temps à s'exécuter. L'exemple suivant modifie la fonction task pour appeler la méthode Concurrency::Context::Yield afin de céder l'exécution au planificateur de tâches et qu'une autre tâche puisse être exécutée.

// A lightweight task that performs a lengthy operation.
void task(void* data)
{   
   task_data_t* task_data = reinterpret_cast<task_data_t*>(data);

   // Create a large loop that occasionally prints a value to the console.
   int i;
   for (i = 0; i < 1000000000; ++i)
   {
      if (i > 0 && (i % 250000000) == 0)
      {
         wstringstream ss;
         ss << task_data->id << L": " << i << endl;
         wcout << ss.str();

         // Yield control back to the task scheduler.
         Context::Yield();
      }
   }
   wstringstream ss;
   ss << task_data->id << L": " << i << endl;
   wcout << ss.str();

   // Signal to the caller that the thread is finished.
   task_data->e.set();
}

Cet exemple produit la sortie suivante :

1: 250000000
2: 250000000
1: 500000000
2: 500000000
1: 750000000
2: 750000000
1: 1000000000
2: 1000000000

La méthode Context::Yield ne cède qu'à un autre thread actif dans le planificateur auquel le thread actuel appartient, à une tâche légère ou à un thread d'un système d'exploitation différent. Cette méthode ne cède pas à un travail qui a été planifié pour s'exécuter dans un objet Concurrency::task_group ou Concurrency::structured_task_group qui n'a pas encore démarré.

Il existe d'autres façons d'activer la coopération entre des tâches de longue durée. Vous pouvez scinder une grande tâche en sous-tâches plus petites. Vous pouvez également activer le surabonnement pendant une tâche de longue durée. Le surabonnement vous permet de créer un nombre de threads plus important que le nombre de threads matériels disponibles. Le surabonnement peut s'avérer particulièrement utile lorsqu'une tâche de longue durée présente une latence élevée, par exemple, lors de la lecture des données à partir d'un disque ou d'une connexion réseau. Pour plus d'informations sur les tâches légères et le surabonnement, consultez Planificateur de tâches (runtime d'accès concurrentiel).

[retour en haut]

Utiliser le surabonnement pour compenser les opérations qui effectuent un blocage ou qui présentent une latence élevée

Le runtime d'accès concurrentiel fournit des primitives de synchronisation, tel que Concurrency::critical_section, qui permettent aux tâches d'effectuer un blocage de manière coopérative et de céder les unes aux autres. Lorsqu'une tâche effectue un blocage ou cède de manière coopérative, le planificateur de tâches peut réaffecter les ressources de traitement à un autre contexte pendant que la première tâche attend des données.

Dans certains cas, vous ne pouvez pas utiliser le mécanisme de blocage coopératif qui est fourni par le runtime d'accès concurrentiel. Par exemple, une bibliothèque externe que vous utilisez peut utiliser un mécanisme de synchronisation différent. Ou encore, lorsque vous exécutez une opération qui peut présenter une latence élevée, par exemple lorsque vous utilisez la fonction ReadFile de l'API Windows pour lire des données à partir d'une connexion réseau. Dans ces cas, le surabonnement peut permettre à des tâches de s'exécuter lorsqu'une autre tâche est inactive. Le surabonnement vous permet de créer un nombre de threads plus important que le nombre de threads matériels disponibles.

Prenons la fonction suivante, download, qui télécharge le fichier à l'URL donnée. Cet exemple utilise la méthode Concurrency::Context::Oversubscribe pour augmenter provisoirement le nombre de threads actifs.

// Downloads the file at the given URL.
string download(const string& url)
{
   // Enable oversubscription.
   Context::Oversubscribe(true);

   // Download the file.
   string content = GetHttpFile(_session, url.c_str());

   // Disable oversubscription.
   Context::Oversubscribe(false);

   return content;
}

Étant donné que la fonction GetHttpFile effectue une opération potentiellement latente, le surabonnement peut permettre à d'autres tâches de s'exécuter pendant que la tâche actuelle attend des données. Pour obtenir la version complète de cet exemple, consultez Comment : utiliser le surabonnement pour compenser la latence.

[retour en haut]

Utiliser les fonctions de gestion de la mémoire simultanée, dans la mesure du possible

Utilisez les fonctions de gestion de la mémoire, Concurrency::Alloc et Concurrency::Free, en présence de tâches de granularité fine qui allouent souvent des petits objets dont la durée de vie est relativement courte. Le runtime d'accès concurrentiel maintient un cache mémoire séparé pour chaque thread en cours de exécution. Les fonctions Alloc et Free allouent et libèrent la mémoire disponible de ces caches sans utiliser de verrous ou de barrières de mémoire.

Pour plus d'informations sur ces fonctions de gestion de la mémoire, consultez Planificateur de tâches (runtime d'accès concurrentiel). Pour obtenir un exemple qui utilise ces fonctions, consultez Comment : utiliser Alloc et Free pour améliorer les performances de la mémoire.

[retour en haut]

Utiliser RAII pour gérer la durée de vie des objets d'accès concurrentiel

Le runtime d'accès concurrentiel utilise la gestion des exceptions pour implémenter des fonctionnalités telles que l'annulation. Par conséquent, écrivez du code sécurisé du point de vue des exceptions lorsque vous appelez le runtime ou une autre bibliothèque qui appelle le runtime.

Le modèle RAII (Resource Acquisition Is Initialization) est un moyen de gérer sans risque la durée de vie d'un objet d'accès concurrentiel dans une portée donnée. Selon le modèle RAII, une structure de données est allouée sur la pile. Cette structure de données initialise ou acquiert une ressource lorsqu'elle est créée et détruit ou libère cette ressource lorsque la structure de données est détruite. Le modèle RAII garantit que le destructeur est appelé avant que la portée englobante ne quitte. Ce modèle est utile lorsqu'une fonction contient plusieurs instructions return. Ce modèle est également utile lorsque vous écrivez du code sécurisé du point de vue des exceptions. Lorsqu'une instruction throw provoque le déroulement de la pile, le destructeur de l'objet RAII est appelé. Par conséquent, la ressource est toujours correctement supprimée ou libérée.

Le runtime définit plusieurs classes qui utilisent le modèle RAII, par exemple, Concurrency::critical_section::scoped_lock et Concurrency::reader_writer_lock::scoped_lock. Ces classes d'assistance portent le nom de verrous à portée limitée. Ces classes procurent plusieurs avantages lorsque vous travaillez avec les objets Concurrency::critical_section ou Concurrency::reader_writer_lock. Le constructeur de ces classes acquiert l'accès à l'objet critical_section ou reader_writer_lock fourni et le destructeur libère l'accès à cet objet. Étant donné qu'un verrou à portée limitée libère automatiquement l'accès à son objet d'exclusion mutuelle lorsqu'il est détruit, vous ne déverrouillez pas l'objet sous-jacent manuellement.

Prenons l'exemple de la classe suivante, account, qui est définie par une bibliothèque externe et ne peut donc pas être modifiée.

// account.h
#pragma once
#include <exception>
#include <sstream>

// Represents a bank account.
class account
{
public:
   explicit account(int initial_balance = 0)
      : _balance(initial_balance)
   {
   }

   // Retrieves the current balance.
   int balance() const
   {
      return _balance;
   }

   // Deposits the specified amount into the account.
   int deposit(int amount)
   {
      _balance += amount;
      return _balance;
   }

   // Withdraws the specified amount from the account.
   int withdraw(int amount)
   {
      if (_balance < 0)
      {
         std::stringstream ss;
         ss << "negative balance: " << _balance << std::endl;
         throw std::exception((ss.str().c_str()));
      }

      _balance -= amount;
      return _balance;
   }

private:
   // The current balance.
   int _balance;
};

L'exemple suivant effectue plusieurs transactions sur un objet account en parallèle. L'exemple utilise un objet critical_section pour synchroniser l'accès à l'objet account, car la classe account n'est pas sécurisée du point de vue de l'accès concurrentiel. Chaque opération parallèle utilise un objet critical_section::scoped_lock pour garantir que l'objet critical_section est déverrouillé lorsque l'opération réussit ou échoue. Lorsque le solde de compte est négatif, l'opération withdraw échoue en levant une exception.

// account-transactions.cpp
// compile with: /EHsc
#include "account.h"
#include <ppl.h>
#include <iostream>
#include <sstream>

using namespace Concurrency;
using namespace std;

int wmain()
{
   // Create an account that has an initial balance of 1924.
   account acc(1924);

   // Synchronizes access to the account object because the account class is 
   // not concurrency-safe.
   critical_section cs;

   // Perform multiple transactions on the account in parallel.   
   try
   {
      parallel_invoke(
         [&acc, &cs] {
            critical_section::scoped_lock lock(cs);
            wcout << L"Balance before deposit: " << acc.balance() << endl;
            acc.deposit(1000);
            wcout << L"Balance after deposit: " << acc.balance() << endl;
         },
         [&acc, &cs] {
            critical_section::scoped_lock lock(cs);
            wcout << L"Balance before withdrawal: " << acc.balance() << endl;
            acc.withdraw(50);
            wcout << L"Balance after withdrawal: " << acc.balance() << endl;
         },
         [&acc, &cs] {
            critical_section::scoped_lock lock(cs);
            wcout << L"Balance before withdrawal: " << acc.balance() << endl;
            acc.withdraw(3000);
            wcout << L"Balance after withdrawal: " << acc.balance() << endl;
         }
      );
   }
   catch (const exception& e)
   {
      wcout << L"Error details:" << endl << L"\t" << e.what() << endl;
   }
}

Cet exemple génère l'exemple de sortie suivant :

Balance before deposit: 1924
Balance after deposit: 2924
Balance before withdrawal: 2924
Balance after withdrawal: -76
Balance before withdrawal: -76
Error details:
        negative balance: -76

Pour obtenir des exemples supplémentaires qui utilisent le modèle RAII pour gérer la durée de vie des objets d'accès concurrentiel, consultez Procédure pas à pas : suppression de travail d'un thread d'interface utilisateur, Comment : utiliser la classe Context pour implémenter un sémaphore coopératif et Comment : utiliser le surabonnement pour compenser la latence.

[retour en haut]

Ne pas créer d'objets d'accès concurrentiel au niveau de la portée globale

Si vous créez un objet d'accès concurrentiel au niveau de la portée globale, un interblocage peut se produire dans votre application.

Lorsque vous créez un objet de runtime d'accès concurrentiel, le runtime crée un planificateur par défaut, si aucun planificateur n'existe déjà. Cela se produit également pour un objet de runtime qui est créé pendant la construction d'objets globale. Toutefois, ce processus utilise un verrou interne, ce qui peut perturber l'initialisation d'autres objets qui prennent en charge l'infrastructure du runtime d'accès concurrentiel. Dans la mesure où ce verrou interne peut être requis par un autre objet d'infrastructure qui n'a pas encore été initialisé, un interblocage peut se produire dans votre application.

L'exemple suivant illustre la création d'un objet Concurrency::Scheduler global. Ce modèle s'applique non seulement à la classe Scheduler, mais également à tous les autres types fournis par le runtime d'accès concurrentiel. Nous vous conseillons de ne pas respecter ce modèle, étant donné qu'il peut provoquer l'interblocage de votre application.

// global-scheduler.cpp
// compile with: /EHsc
#include <concrt.h>

using namespace Concurrency;

static_assert(false, "This example illustrates a non-recommended practice.");

// Create a Scheduler object at global scope.
// BUG: This practice is not recommended because it can cause deadlock.
Scheduler* globalScheduler = Scheduler::Create(SchedulerPolicy(2,
   MinConcurrency, 2, MaxConcurrency, 4));

int wmain() 
{   
}

Pour obtenir des exemples sur la façon de créer correctement des objets Scheduler, consultez Planificateur de tâches (runtime d'accès concurrentiel).

[retour en haut]

Ne pas utiliser d'objets d'accès concurrentiel dans les segments de données partagées

Le runtime d'accès concurrentiel ne prend pas en charge l'utilisation d'objets d'accès concurrentiel dans une section de données partagées, par exemple, une section de données créée par la directive data_seg #pragma. Un objet d'accès concurrentiel partagé au delà des limites de processus peut entraîner un état incohérent ou non valide du runtime.

[retour en haut]

Voir aussi

Tâches

Comment : utiliser Alloc et Free pour améliorer les performances de la mémoire

Comment : utiliser le surabonnement pour compenser la latence

Procédure pas à pas : suppression de travail d'un thread d'interface utilisateur

Concepts

Meilleures pratiques sur le runtime d'accès concurrentiel

Bibliothèque de modèles parallèles

Bibliothèque d'agents asynchrones

Planificateur de tâches (runtime d'accès concurrentiel)

Structures de données de synchronisation

Comparaison de structures de données de synchronisation avec l'API Windows

Autres ressources

Comment : utiliser la classe Context pour implémenter un sémaphore coopératif

Meilleures pratiques de la Bibliothèque de modèles parallèles

Meilleures pratiques de la Bibliothèque d'agents asynchrones

Historique des modifications

Date	Historique	Motif
Mars 2011	Ajout d'informations sur le risque d'interblocage au niveau de la portée globale.	Commentaires client.