Lecteur/graveur sans verrou

Question

J'ai des données qui sont à la fois lues et mises à jour par plusieurs threads. Les lectures et les écritures doivent être atomiques. Je pensais à le faire comme ceci:

// Values must be read and updated atomically 
struct SValues 
{ 
    double a; 
    double b; 
    double c; 
    double d; 
}; 

class Test 
{ 
public: 
    Test() 
    { 
     m_pValues = &m_values; 
    } 

    SValues* LockAndGet() 
    { 
     // Spin forver until we got ownership of the pointer 
     while (true) 
     { 
      SValues* pValues = (SValues*)::InterlockedExchange((long*)m_pValues, 0xffffffff); 
      if (pValues != (SValues*)0xffffffff) 
      { 
       return pValues; 
      } 
     } 
    } 

    void Unlock(SValues* pValues) 
    { 
     // Return the pointer so other threads can lock it 
     ::InterlockedExchange((long*)m_pValues, (long)pValues); 
    } 

private: 
    SValues* m_pValues; 
    SValues m_values; 
}; 

void TestFunc() 
{ 
    Test test; 

    SValues* pValues = test.LockAndGet(); 

    // Update or read values 

    test.Unlock(pValues); 
} 

Les données sont protégées en volant le pointeur pour chaque lecture et d'écriture, ce qui devrait threadsafe, mais il nécessite deux instructions enclenchées pour chaque accès. Il y aura beaucoup de lectures et d'écritures et je ne peux pas dire à l'avance s'il y aura plus de lectures ou plus d'écritures.

Cela peut-il être plus efficace que cela? Cela se verrouille également lors de la lecture, mais comme il est tout à fait possible d'avoir plus d'écritures puis de lectures, il n'y a pas lieu d'optimiser la lecture, à moins de ne pas infliger de pénalité à l'écriture. Je pensais à lire l'acquisition du pointeur sans une instruction verrouillée (avec un numéro de séquence), copier les données, puis avoir un moyen de dire si le numéro de séquence avait changé, auquel cas il devrait réessayer. Cela exigerait cependant des barrières de mémoire, et je ne sais pas si cela pourrait améliorer la vitesse.

----- ----- EDIT

Merci à tous, grands commentaires! Je n'ai pas réellement exécuté ce code, mais je vais essayer de comparer la méthode actuelle avec une section critique plus tard aujourd'hui (si j'ai le temps). Je suis toujours à la recherche d'une solution optimale, donc je reviendrai aux commentaires les plus avancés plus tard. Merci encore!

Answer 1

Ce que vous avez écrit est essentiellement un spinlock. Si vous allez faire cela, alors vous pourriez aussi bien utiliser un mutex, tel que boost::mutex. Si vous voulez vraiment un spinlock, utilisez un système fourni par le système, ou un d'une bibliothèque plutôt que d'écrire le vôtre.

D'autres possibilités incluent une forme de copie-sur-écriture. Stocker la structure de données par pointeur, et juste lire le pointeur (atomiquement) sur le côté de lecture. Du côté écriture, créez une nouvelle instance (en copiant les anciennes données si nécessaire) et échangez le pointeur de manière atomique. Si l'écriture a besoin de l'ancienne valeur et qu'il y a plus d'un éditeur, vous devrez soit faire une boucle d'échange de comparaison pour vous assurer que la valeur n'a pas changé depuis la lecture (attention aux problèmes ABA), soit un mutex pour les écrivains. Si vous faites cela alors vous devez faire attention à la façon dont vous gérez la mémoire --- vous avez besoin d'un moyen de récupérer des instances des données quand aucun thread ne le référence (mais pas avant).

Answer 2

Il existe plusieurs façons de résoudre ce problème, en particulier sans mutex ou mécanismes de verrouillage. Le problème est que je ne suis pas sûr quelles sont les contraintes sur votre système. Rappelez-vous que les opérations atomiques sont souvent déplacées par les compilateurs en C + +.

En général, je résoudre le problème comme celui-ci:

multiples producteurs unique aux consommateurs en 1 seul producteur-consommateur par un seul fil d'écriture. Chaque thread écrit dans sa propre file d'attente. Un thread de consommation unique qui rassemble les données produites et les stocke dans un stockage de données à consommateur unique et à plusieurs lecteurs. La mise en œuvre pour cela est beaucoup de travail et seulement recommandé si vous faites une application à temps critique et que vous avez le temps de mettre cette solution.

Il y a plus de choses à lire sur ce, depuis la mise en œuvre est la plate-forme spécifique:

atomique etc opérations sur les fenêtres/Xbox360: http://msdn.microsoft.com/en-us/library/ee418650(VS.85).aspx

Le multithread seul producteur unique consommateur sans serrures :
http://www.codeproject.com/KB/threads/LockFree.aspx#heading0005

Qu'est-ce que pour "volatile" est vraiment et peut être utilisé:
http://www.drdobbs.com/cpp/212701484

Herb Sutter a écrit un bon article qui vous rappelle les dangers de la rédaction de ce type de code: http://www.drdobbs.com/cpp/210600279;jsessionid=ZSUN3G3VXJM0BQE1GHRSKHWATMY32JVN?pgno=2