Dans .NET comment puis-je savoir si une classe ou une méthode est thread safe ou pas? Est-il par défaut pas thread sûr?Existe-t-il un attribut pour indiquer que la classe ou la méthode est sûre pour les threads dans .NET?
Ce n'est pas un attribut pour cela: vous devez lire la documentation pour chaque élément qui vous intéresse. Vous ne pouvez pas sécuriser un thread en lui ajoutant simplement un attribut. C'est comme prendre une orange et mettre un autocollant qui dit «Apple».
Bien sûr, la même chose est vraie pour la sérialisation et ça ne les a pas arrêtés là, mais quand même: pas d'attribut. Lisez les docs.
Toutes les méthodes et propriétés statiques sont supposées être thread safe par défaut (ie sauf si documenté autrement), par exemple méthodes l'hypothèse c'est qu'ils ne le sont pas. – Richard
En supposant qu'une méthode n'est pas sûre pour les threads lorsqu'elle ne cause aucun dommage, en supposant que l'on est thread safe quand elle ne peut pas être méchante. Votre mieux de ne rien présumer est thread safe sauf indication contraire. – JoshBerke
J'ai eu mon dos à Joel Coehoorn sur celui-ci, il serait facile de «simuler» de telles réclamations.
Pourquoi ne pas ajouter le texte threadsafe dans la description de la fonction
Je ne m'inquiéterais pas tellement de "truquer". Mais la simultanéité est difficile: il est très probable qu'un bogue s'est glissé et que cet attribut est juste incorrect. –
Mais si l'attribut est incorrect, il est probable que la documentation (le cas échéant) serait tout aussi incorrecte. –
Je suis totalement d'accord @JimMischel, mais Joel n'était pas celui qui plaide pour la documentation. Au moins, les attributs sont lisibles par une machine, permettant, au minimum, une énumération automatisée, un filtrage, un rapport etc. des méthodes attribuées, et potentiellement même certaines formes faibles d'analyse statique et/ou de prévention d'erreur.Les attributs sont la voie à suivre, mais vous aurez besoin d'un système complexe et complet pour capturer la sémantique de la concurrence de manière vraiment utile. Pour .NET, je ne suis pas au courant d'une telle conception ou proposition. –
Il n'y a pas de scénario de cas d'utilisation de faire une classe synchronisée, dans la mesure où la méthode que vous concerne après l'utilisation de style de codage:
using System.Runtime.CompilerServices;
[MethodImpl(MethodImplOptions.Synchronized)]
void MyMethod()
{
DoSomething();
}
Le problème est; Cela n'implique toujours pas que la méthode est sûre pour les threads car un autre thread pourrait appeler une méthode différente qui n'a * pas * la méthode [MethodImpl], se saccageant ainsi mutuellement. De même, même si tous les champs sont en lecture seule, les champs des objets enfants peuvent être modifiables et provoquer des problèmes. –
Même si ce "style de codage" * pourrait * signifier quelque chose (voir de nombreux autres commentaires sur cette page), le drapeau 'MethodImplOptions.Synchronized' a la signification inverse de ce que l'OP recherche. Ce drapeau est destiné à indiquer que la méthode n'est pas ** thread-safe. De la documentation: "La méthode peut être exécutée par un seul thread à la fois." –
Il est possible de faire tous les accès à votre série série via IContributeObjectSink/IContextAttribute bien que cela va souffrir d'un grand succès de performance car il faudra votre objet à sous-classe MarshalByRefObject, surcharge de création de contexte, etc ...
Non, et ce serait inutile.
Supposons que j'ai un fil liste de sécurité, il a trois Thread Safe ™ méthodes:
void Add(something);
void Remove(index);
int GetCount();
something GetElementAt(index);
Enfiler un:
for 1 to 100 do
list.Add(12);
Discussion deux et trois:
while(list.GetCount() >0)
{
list.Remove(0);
}
Le code ci-dessus va planter (tôt ou tard) car la liste peut changer entre le moment où vous appelez GetCount et Remove
À quoi aimeriez-vous qu'un tel attribut serve? – AnthonyWJones
Peut-être une sorte de documentation de code pour avertir l'utilisateur de classe –
S'il veut juste la documentation, il pourrait le mettre dans la section