Classes volatiles en C++

Question

J'ai une question concernant un mot-clé volatile pour lequel je n'arrive pas à trouver de réponse.

Dans mon application, j'ai une classe de données qui est partagée en tant que tampon d'état entre les threads, et j'ai besoin qu'il soit mis à jour régulièrement à partir de plusieurs threads.

classe ressemble à ceci:

class CBuffer 
{ 
    //Constructor, destructor, Critical section initialization/destruction 
    //... 

    volatile wstring m_strParam; 
    //... 
    void InterlockedParamSetter(const wstring &strIn); 
    wstring InterlockedParamGetter(); 

    ParamSetter(const wstring &strIn); 
    wstring ParamGetter(); 

    Lock(); 
    Unlock(); 
} 

void CBuffer::InterlockedParamSetter(const wstring &strIn) 
{ 
    Lock(); 
    const_cast<wstring>(m_strParam) = strIn; 
    Unlock(); 
} 

//... other f-ns 

Mais le compilateur se plaint de la conversion const_cast. Il semble presque que j'utilise abusivement le mot clé volatile, mais en même temps, je ne peux pas laisser les params être mis en cache entre les appels, parce que si deux ou trois threads vont les assigner, quelque chose peut mal se passer.

Comment écrire des classes sécurisées thread/cache en C++?

P.S .: Jusqu'à présent, le verrouillage n'est pas le goulot d'étranglement, et les verrous sont assez simples, donc pour l'instant, la sérialisation et le verrouillage ne sont pas un problème du point de vue des performances. Bien sûr, s'il y a un meilleur algorithme, j'écouterai volontiers.

EDIT: Je suis toujours pas clair ...

Considérons cet exemple (inline + temps lien codegen);

void Thread1Func() 
{ 
    //Unrolled, inlined InterlockedParamSetter() 
    EnterCriticalSection(&cs); 
    WriteTo(CBuffer::m_strParam);//write to buffer, wstring not volatile, cache it 
    LeavCriticalSection(&cs); 
    //Unroll end 

    //DoSomethingElse 

    //!!!!Thread 2 does InterlockedParamSetter 
    //which causes wstring::reserve and invalidates old pointers!!!! 

    //Unrolled, inlined InterlockedParamSetter() 
    EnterCriticalSection(&cs); 
    WriteTo(CBuffer::m_strParam);//oh, good, we have a pointer to old buffer 
    //cached in one of the registers, write to it -> access violation 
    LeavCriticalSection(&cs); 
    //Unroll end 
} 

Answer 1

Dans le code portable, volatile a absolument rien à voir avec multithreading.

En MSVC, comme une extension, volatile types natifs simples aux qualifiés tels que int peut être utilisé avec des opérations simples de lecture et de stockage pour les accès atomiques, mais ce n'a pas étendre à lecture-modification-écriture accède à un tel comme i++ ou à des objets de type classe tels que std::string. Pour garantir un accès sécurisé à votre variable m_strParam à partir de plusieurs threads, chaque thread doit verrouiller le mutex associé avant d'accéder au m_strParam et le déverrouiller ensuite. Le verrouillage/déverrouillage assurera que la valeur correcte de m_strParam est vue par chaque thread --- il n'y aura pas de mise en cache du pointeur interne si un autre thread a modifié la variable par le verrou suivant.

Si vous utilisez correctement les verrous, vous n'avez pas besoin du qualificatif volatile et vous n'avez pas besoin d'utiliser const_cast.

Answer 2

std::string (et std::wstring) n'a pas été conçu pour être volatil et je vous conseille de ne pas utiliser de cette façon.

La méthode habituelle pour garantir la sécurité des threads consiste à utiliser des mutex, des sémaphores, le cas échéant, et à éviter l'utilisation de variables globales.

Et comme Marcus Lindblom mentionner, il y a généralement une clôture lecture/écriture dans les mécanismes de verrouillage qui prennent soin de traiter les problèmes de mise en cache potentiels. Donc, vous devriez être en sécurité.

Answer 3

Vous devez const_cast strIn pas m_strParam:

m_strParam = const_cast<wstring> (strIn); 

Il n'y a pas d'idiomes généralement acceptés sur fil/cache des classes de sécurité en C++, comme la norme C++ qui prévaut actuellement et ne dit rien sur la programmation concurrente. volatile ne fait aucune garantie d'atomicité et est inutile dans l'écriture de programmes portables, thread-safe. Voir ces liens:

• Should volatile Acquire Atomicity and Thread Visibility Semantics?
• Volatile: Almost Useless for Multi-Threaded Programming

Answer 4

Pas besoin d'utiliser volatile. Un compiler memory barrier devrait être suffisant. Le Lock/Unlock est toujours nécessaire, cependant. C'est,

class CBuffer 
{ 
    //Constructor, destructor, Critical section initialization/destruction ... 
    wstring m_strParam; 
}; 

void CBuffer::InterlockedParamSetter(const wstring &strIn)  
{ 
    Lock(); 
    //compiler-specific memory barrier; 
    m_strParam = strIn; 
    //compiler-specific memory barrier; 
    Unlock(); 
} 

Bien que sur certains compilateurs, le mot-clé volatile a la même signification que la barrière de mémoire lorsqu'elle est appliquée à des types non primitifs comme wstring.Exemple: VC++

mémoire de marquage avec une barrière de mémoire est similaire à la mémoire de marquage avec le mot-clé volatile (C++). Cependant, une barrière de mémoire est plus efficace parce que ...