Ich wurde von Code-Verträgen, die in .NET 4 eingeführt wurden, sehr gefesselt (allerdings mit Hilfe von DevLabs). Aber ein Kleingedrucktes kühlte mich ziemlich ab. Hier ist was es sagt:
Der größte für mich ist der erste. Ich weiß nicht, ob jemand Singlethread-Apps mehr schreibt. Wenn also Code-Verträge Multi-Threading nicht unterstützen können, sehe ich nicht viel davon. Oder vielleicht sollte ich nicht zu sehr darüber gestresst werden, denn Nachbedingungen dienen dazu, die Interna der Methode selbst zu bestätigen, die Unit-getestet werden kann.
Übrigens, ich habe nichts gefunden, und ich habe nicht versucht, meinen Code zu zerlegen, um zu sehen, wo Vorbedingungen eingegeben werden. Ich nehme an, in einer einfachen Methode, wenn lock () zuerst geht, ist es einfach, Prüfungen direkt danach zu injizieren, aber in einer ziemlich komplizierten Methode, wenn das Sperren irgendwo in der Mitte auftritt, kann es ein Problem sein. Oder wenn andere Mechanismen als lock () verwendet werden.
Es gibt derzeit keine Problemumgehung, wenn Nachbedingungen innerhalb einer threadsicheren Methode außerhalb der Sperre aufgerufen werden, außer dass sie nicht verwendet werden.
Nicht wirklich ein Problem - wenn Sie sich selbst außerhalb einer Lock-Anweisung in der thread-sicheren Methode überprüfen, können Sie auch auf ein Problem stoßen. Passen Sie Ihre Implementierung für diese kleine Einschränkung an. Die Frage ist, wie der Code-Rewriter wissen wird, dass Sie eine Ressource sperren müssen? Ich denke, diese Einschränkung wird noch lange anhalten.
.NET basiert auf einem binären Rewriter, wodurch der Build langsamer wird.
Ja, einige IL müssen ausgewertet, generiert und gespeichert werden, um einige IL zu erzeugen, neue Abhängigkeiten = mehr Zeit natürlich aufzubauen.
Die Verwendung von Codeverträgen kann ebenfalls einen Laufzeitleistungstreffer verursachen.
Auch nicht ungewöhnlich oder ein Problem, mehr Code (generiert für die Code-Verträge) = langsamer. Sie haben nur mehr Code im Grunde und was Sie möglicherweise auch durch eine Proxy-Klasse laufen, so gibt es mehr Code + mögliche Proxy.
Kann nicht für sicherheitsrelevante Prüfungen verwendet werden, da sie zur Laufzeit durch Behandlung des ContractFailed-Ereignisses umgangen werden können.
Ja, tu das nicht. Sie müssen die Baugruppe nicht einmal entfernen oder neu zusammenbauen, um eine mögliche Sicherheitsüberprüfung zu überspringen. Behalten Sie sicherheitsrelevante Kontrollflüsse auf dem Server (sei es web oder db), wenn möglich, oder versuchen Sie, Ihren Code mit den besten Fähigkeiten zu verschleiern, wenn Sie lokal sind.
Sie scheinen das "Schreiben von Multithread-Apps" mit "jede Klasse threadsicher" zu verwirren. Abgesehen von der tricky Frage der Definition des Begriffs "Thread-Sicherheit" Ich würde vorschlagen, dass nur sehr wenige Ihrer Klassen Locking in den meisten Apps verwenden sollten.
Im Allgemeinen schreibe ich viele Klassen, die nicht explizit Thread-sicher sein wollen, aber auch keine Thread-Abhängigkeiten haben. Sie gehen davon aus, dass wenn Sie sie aus mehreren Threads verwenden, Sie nur von einem Thread zu einem Zeitpunkt mit entsprechenden Speicherbarrieren, um sicherzustellen, dass in einem Thread vorgenommene Änderungen sichtbar sind, in welchem Thread sie als nächstes verwendet / p>
Es gibt dann relativ wenige Klassen, die die notwendige Koordination durchführen.
Nun, es ist möglich, dass die Probleme mit den Code Contracts diese wenigen Klassen so schwach machen, dass das ganze Denken zum Einsturz kommt ... aber ich würde das nicht voraussetzen.
Ich bin etwas vorsichtiger in Bezug auf die Probleme Code Contracts werden mit dem C # -Compiler konfrontiert werden mehr tun mehr Arbeit umschreiben Sie Ihren Code ... Ich weiß nicht, ob das Contracts-Team Probleme Iterator Blöcke noch angesprochen hat, aber auch wenn Sie müssen es wieder tun, wenn C # 5 mit asynchronen Methoden herauskommt ...
Tags und Links c# multithreading .net-4.0 code-contracts