Discussion :

[kidpaddle2]

Bonjour,

Tout est dans le titre. J'aimerais en particulier vérifier quelque chose : j'ai une instance de classe dans le main. Cette classe lance un thead qui va être LE SEUL à lire/écrire dans la classe. A-t-on besoin de faire du thread-safe pour une pareille utilisation ?

Bien entendu, si vous pouviez me résumer dans quels cas est-on obligés de faire attention au thread-safe, j'apprécierais beaucoup.

Merci d'avance.

Cordialement,

Kidpaddle2

[JolyLoic]

Pour moi, on a toujours besoin de faire du thread-safe. La fait de dire qu'un objet sera utilisé dans un thread et un seul, et qu'il n'a donc besoin d'aucune fonction de protection (comme des mutex) est une manière de faire du thread safe (qui a l'avantage d'être aisée à mettre en œuvre, et peu coûteuse en ressource. C'est en fait probablement la meilleure manière de faire, quand ça a du sens).

Des fonctions de protection contre un accès concurrent sont nécessaires lorsqu'une ressource va être utilisée en même temps par plusieurs threads, et qu'un de ces threads au moins va modifier cette ressource (et sauf si accès et modification sont effectuée de manière atomique).

[3DArchi]

Bonsoir,

Des fonctions de protection contre un accès concurrent sont nécessaires lorsqu'une ressource va être utilisée en même temps par plusieurs threads, et qu'un de ces threads au moins va modifier cette ressource (et sauf si accès et modification sont effectués de manière atomique).

Je me permet de rebondir car j'ai souvent vu l'utilisation de mutex pour se protéger d'un accès concurrent 'à risque' en pensant que ce mutex allait résoudre d'un coup les problèmes de concurrence.
Or le mutex n'est là, si on résume, que pour rendre 'atomique' une opération qui ne l'est pas au départ. Or il faut faire attention à avoir une conception qui soit aussi pensée dans un cadre de concurrence. Un classique (liée à des conceptions bancales justement) est le mélange d'échange entre thread à la fois par un mécanisme de message/boîte aux lettres et la lecture ou la modification d'état par fonction. On peut avoir des comportements totalement erratiques en fonction des politiques d'ordonnancement, des contextes d'exécution, etc. Tout simplement parce qu'un message sera reçu avant ou après l'accès à une fonction alors qu'on attendait à ce que le traitement soit déjà en cours.
Tout ça pour dire qu'il me semble qu'on tend aujourd'hui à minimiser les partages de données entre différents threads au profit de mécanisme d'échange de type boîtes aux lettres (cf les articles de Herb Sutter et Use Threads Correctly = Isolation + Asynchronous Messages et Prefer Using Active Objects Instead of Naked Threads par exemple)

[kidpaddle2]

Merci pour vos réponses, j'avais un doute. =)