Smart Pointer et le Multithreading

Bonjour a tous. Voilà cela fait quelque temps que je bloque au niveau de la conception d'une classe: une classe de SmartPtr mais qui soit thread safe. Ce qui suit est une ebauche de la declaration de cette classe:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

template<typename Ty,bool IsMultiThread = false> class SmartPtr;     template<typename Ty> class SmartPtr<Ty,true> { public: template<typename Ty> class Proxy;   SmartPtr(); explicit SmartPtr(Ty* Elt); .../...   SmartPtr::Proxy<Ty>* operator -> (); const SmartPtr::Proxy<Ty>* operator -> () const;   //??? operator *(); <--- le probleme est ici.     ../...   };

---

je veux eviter les instructions du genre:

Code:

---

1 2 3 4 5 6 7 8

struct A { int val; A(int i); };   SmartPtr<A> sp(new A(10) ); int* pi = &(*sp).val;

---

Toute proposition es la bienvenue.
Merci pour votre aide.

Qu'est ce que tu entends par "je veux éviter les trucs du genre" ?

Qu'est que tu veux à la place ?

Jettes un oeil au chapitre de Modern C++ Design (D'Andrei Alexandrescu) qui est dédié à ce sujet. Tu devrais trouver ce chapitre en ligne sur le site de l'éditeur dans mes souvenirs.

et celle de boost, elle est multithread ?
y a-t-il un probleme a les utiliser avec les thread de Qt, de pthread ou autre ?

Je ne sais pas pour les shared_ptr<>, mais les intrusive_ptr<> le seront si tu implémente le verrouillage nécessaire dans tes fonctions d'incrémentation/décrémentation du comptage de référence. Là, tu pourras utiliser des mutex, ou encore sous Windows, les fonctions Win32 InterlockedIncrement() et InterlockedDecrement(), etc.

Un truc bien avec les smart pointers, c'est qu'on n'a plus besoin de synchronisation/verrouillage une fois que le nombre de références est inférieur ou égal à 1, permettant une suppression sans problèmes.

Les smart pointers de boost sont déjà thread-safe.
Par contre shared_ptr n'est pas lock-free (problème lié à sa taille, deux mots et non un)

mchk0123 a dit:

Citation:

---

Qu'est ce que tu entends par "je veux éviter les trucs du genre" ?
Qu'est que tu veux à la place ?

---

Je veux reourner un "handle" a mon pointeur que je peux verouiller a dans le ctor et deverouiller dans le dtor.

Luc Hermitte a dit:

Citation:

---

Jettes un oeil au chapitre de Modern C++ Design (D'Andrei Alexandrescu) qui est dédié à ce sujet. Tu devrais trouver ce chapitre en ligne sur le site de l'éditeur dans mes souvenirs

---

Oui justement il traite de tout sauf de l'operator *().

Quand aux smart pointers de boost ils sont thread safe uniquement lors du comptage de reference mais pas au niveau des operateurs d'indirection
(*, ->).

Verrouiller de manière exclusive l'indirection serait probablement stupide.
En particulier, d'habitude les accès qui ne modifient rien peuvent parfaitement s'executer de manière simultanée.

Je confirme, pour les structures de données à accés concurrent, d'habitude on fait du "lock on write" et pas du "lock on read". Principe valable pour toute ressource partagée.

Sauf si t'es en temps réel ou si les accés sont fréquents et critiques, auquel cas tu lock encore moins. Tu bufferise tout ou partie des "write" dans une file d'attente (journalisation NFTS, messages queues Windows, filemaps, ...). Tu lock juste le temps de faire les "write" en batch et vider la file.

Pendant que j'y suis tu peux même faire l'alloc pooling sur tes smart-pointers, si tu en crée en pagaille.

loufoque a dit:

Citation:

---

Verrouiller de manière exclusive l'indirection serait probablement stupide.
En particulier, d'habitude les accès qui ne modifient rien peuvent parfaitement s'executer de manière simultanée

---

Desole, mais c'est un "non sense" car durant un acces en lecture il faut verouiller l'objet pour empecher toute ecriture.
Notez aussi qu'une specialisation pour les cas non multithread existe.

Posons le probleme autrement:

Nous avons 3 possiblites:
1. Aucun support multithread n'est apporte par la classe SmartPtr
2. SmartPtr est verrouiller uniquement durant le comptage des references.
3. Le SmartPtr est totalement thread safe.

1/tres dangereux, car une classe qui utilise un SmartPtr devra gerer sa propre synchronosation et celle du SmartPtr. D'ailleur un objet constant de cette classe devra lui aussi etre synchronise (ce qui est logiquement faux).

2/Dans ce cas nous avons 2 problemes:
a. SmartPtr devient non hommogene (la classe est thread safe ou pas?)
b. Il sera necessaire d'introduire un autre verrou au niveau des classes qui utilse SmartPtr, ce qui augmenterait considerablement la taille de ces classes.

3/ c'est la solution la plus fiable, mais l'ideal serait que un objet SmartPtr se comporte comme un Lock,(SmartPtr derive de la classe Lock par exemple) et ainsi on evite l'utilisation un objet lock au niveau des classes clientes de SmartPtr. Seulement il faudrait resoudre le probleme initial qui est celui de l'operateur operator*()

N'oubliez pas que tout ceci rentre dans le cadre de composants reutilsable.
merci pour votre aide.

Citation:

---

Envoyé par adel_dz

Desole, mais c'est un "non sense"

---

Et merde à trop discuter j'en ai râté mon rendez-vous chez le neurologue ...
Bon je vous quittes, je passe la main aux autres...

:blt:

Citation:

---

Desole, mais c'est un "non sense" car durant un acces en lecture il faut verouiller l'objet pour empecher toute ecriture.

---

Puisque c'est l'utilisateur qui gère le verrou pour l'écriture, c'est à lui de voir s'il a une écriture potentielle en cours en même temps qu'une lecture.

Ta définition de thread-safe doit être mauvaise de toutes façons.

loufoque a dit:

Citation:

---

Puisque c'est l'utilisateur qui gère le verrou pour l'écriture, c'est à lui de voir s'il a une écriture potentielle en cours en même temps qu'une lecture.

---

Non ce n'est pas tjrs le cas. Soit une librerie X contenat une classe String basee sur la technique COW, et qui utilse SmartPtr comme client. Deux objets de cette classe disperses dans le programme peuvent pointer sur la meme chaine de caracteres sans que les clients de la classe String le sachent.