Gestion des ressources partagées dans l'application multithread shared_ptr?

Question

Je dois partager un BLOB dans une application multithread et je suis actuellement à la recherche d'une approche shared_ptr/weak_ptr, mais je ne suis pas sûr que ce soit correct.

Il existe un thread de travail qui crée une classe de ressources (nouvelle CResource). CResource peut être assez volumineux, donc je veux éviter les copies supplémentaires.

Ensuite, il existe un autre thread UI, je veux PostMessage avec pointeur vers CResource.

Mais le thread de travail peut quitter plus vite que le thread UI ou vice versa. Et le travailleur n'a aucun moyen de savoir si le message a été traité. Donc je me demande si je peux créer un (new shared_ptr) dans le thread de travail, puis passer une (nouvelle weak_ptr) à la fonction postmessage, et, si cela prend soin du nettoyage automatique. Donc, si le thread de travail détruit son shared_ptr, le thread de l'interface utilisateur retournera false sur weak_ptr.lock, il n'y aurait donc pas besoin de synchronisation supplémentaire et de gestion des ressources.

Également ce qui se passera si le travailleur crée une nouvelle ressource CRESource, le thread de l'interface utilisateur commence à s'exécuter, worker appelle shared_ptr.reset (new CResource)? Il semble que le thread UI peut commencer à lire les données supprimées à ce stade si aucun verrouillage n'est fait?

Ou si le thread principal se termine, et supprime son shared_ptr pendant le nettoyage, le weak_ptr va-t-il se balancer?

Je suis un peu nouveau dans tout ce truc partagé/weak_ptr, et la documentation est un peu confuse pour moi pour l'instant, alors excusez-moi si c'est une question stupide.

Je serais reconnaissant si quelqu'un pourrait me dire si cela vaut la peine d'enquêter sur cette option, ou s'il y a plusieurs pièges et une approche ancienne école est meilleure?

Answer 1

weak_ptr est généralement utilisé pour rompre les cycles dans des structures de données interdépendantes. Je crois que d'après la description que vous avez fournie, cela fonctionnera. Une fois que weak_ptr::lock réussit, vous êtes bon jusqu'à ce que vous laissez le shared_ptr retourné hors de la portée. Cependant, je ne comprends pas pourquoi vous ne donnez pas simplement le shared_ptr au thread de l'interface utilisateur. Ensuite, vous n'avez pas à vous soucier du shared_ptr dans le thread de travail disparaissant et prenant votre accès BLOB avec lui. Le partage de données comme celui-ci est précisément ce pour quoi shared_ptr est idéal.