Renvoyer des pointeurs de manière sûre pour les threads

Question

Supposons que je dispose d'une collection thread-safe de choses (appelons-la ThingList), et je souhaite ajouter la fonction suivante.

Thing * ThingList::findByName(string name) 
{ 
    return &item[name]; // or something similar.. 
} 

Mais en faisant cela, je l'ai confié la responsabilité de la sécurité des threads au code d'appel, qui devrait faire quelque chose comme ceci:

try 
{ 
    list.lock(); // NEEDED FOR THREAD SAFETY 
    Thing *foo = list.findByName("wibble"); 
    foo->Bar = 123; 
    list.unlock(); 
} 
catch (...) 
{ 
    list.unlock(); 
    throw; 
} 

Il est évident qu'un verrou RAII/déverrouiller l'objet serait simplifier/supprimer le try/catch/unlock, mais il est toujours facile pour l'appelant d'oublier.

Il y a quelques alternatives que j'ai regardé:

• Thing Retour en valeur, au lieu d'un pointeur - bien à moins que vous devez modifier la chose
• Ajouter la fonction ThingList::setItemBar(string name, int value) - fin, mais ils tendent à proliférer
• Renvoyer un objet pointeur qui verrouille la liste à la création et la déverrouille à nouveau en cas de destruction. Vous ne savez pas si c'est une bonne ou une mauvaise pratique ...

Quelle est la bonne approche pour y faire face?

Answer 1

Il n'y a pas une seule "bonne approche"; Cela dépend des besoins de votre application.

Dans la mesure du possible, renvoyez les éléments par valeur ou renvoyez une copie indiquant que l'appelant peut faire ce qu'il veut.

Une variante de ce qui précède est de retourner une copie modifiable, puis de fournir un moyen de fusionner de manière atomique un objet modifié dans la liste. Quelque chose comme:

Thing t = myThingList.getThing(key); 
t.setFoo(f); 
t.setBar(b); 
myThingList.merge(t);  // ThingList atomically updates the appropriate element 

Cependant, cela peut causer des problèmes si plusieurs threads tentent de mettre à jour le même objet. L'idée de "l'objet pointeur" semble cool, mais je soupçonne que cela conduirait à des bogues difficiles à trouver quand un verrou ne se libère pas quelque part.

Je voudrais essayer de garder tout le code de verrouillage/déverrouillage dans ThingList, donc les fonctions ThingList::set... sont probablement ce que je ferais.

Answer 2

magasin et retour boost :: shared_ptr s

vous devez verrouiller lors de l'accès, mais vous êtes en sécurité après le déverrouillage