Contratti di codice - bello, al limite, ma non pronto per la prima serata?

Question

Sono rimasto davvero affascinato dai contratti di codice introdotti in .NET 4 (anche se con l'aiuto di DevLabs). Ma una bella stampa mi ha raffreddato un po '. Ecco cosa dice:

• Attualmente non vi è alcuna soluzione al problema quando le postcondizioni vengono richiamate al di fuori del blocco in un metodo thread-safe eccetto per non utilizzarle.
• .NET si basa su un programma di reindirizzamento binario, rendendo così la costruzione più lenta.
• L'utilizzo di contratti di codice può inoltre causare un problema di prestazioni in fase di esecuzione.
• Non può essere utilizzato per i controlli di sicurezza perché possono essere aggirati in fase di esecuzione gestendo l'evento ContractFailed.

Il più grande per me è il primo. Non so se qualcuno scriva più app a thread singolo. Quindi se i contratti di codice non sono in grado di supportare il multithreading, non li vedo molto. O forse non dovrei sottolinearlo troppo perché le postcondizioni servono a far valere gli interni del metodo stesso, che può essere testato unitamente.

BTW, non ho trovato nulla e non ho provato a smontare il mio codice per vedere dove sono state iniettate le precondizioni. Suppongo in un metodo semplice quando lock() va per primo, è semplice iniettare i controlli subito dopo, ma con un metodo piuttosto complicato, quando il blocco avviene da qualche parte nel mezzo, potrebbe essere un problema. O se vengono utilizzati altri meccanismi diversi da lock().

Answer 1

Attualmente non vi è alcuna soluzione al problema quando le postcondizioni vengono chiamate al di fuori del blocco in un metodo thread-safe ad eccezione di non li usa.

Non proprio un problema: se si effettua un controllo all'esterno di un'istruzione di blocco in modalità thread-safe è possibile eseguire anche un problema. Regola la tua attuazione per questa piccola 'limitazione'. La domanda è: in che modo il rewriter del codice saprà che è necessario bloccare una risorsa? Penso che questa limitazione rimarrà per molto tempo.

.NET si basa su un programma di riscrittura binario, rendendo la costruzione più lenta.

Sì, alcuni IL devono essere valutati, generati e salvati per iniettare alcune nuove dipendenze di IL = più tempo ovviamente.

L'utilizzo di contratti di codice può inoltre comportare un calo delle prestazioni in fase di esecuzione.

Anche non insolito o un problema, più codice (generato per i contratti di codice) = più lento. Hai solo più codice in pratica e cosa potresti eseguire attraverso una classe proxy, quindi c'è più codice + possibile proxy.

Non può essere utilizzato per i controlli di sicurezza perché possono essere aggirati in fase di esecuzione gestendo l'evento ContractFailed.

Sì, non farlo. Non è nemmeno necessario smontare/rimontare il gruppo per saltare un potenziale controllo di sicurezza. Mantenere eventuali flussi di controllo relativi alla sicurezza sul server (sia esso web o db), se possibile, o cercare di offuscare il codice alla migliore abilità se locale.

Answer 2

Sembra che tu stia confondendo "scrivere app multi-threaded" con "rendere ogni classe thread-safe". Lasciando da parte il tricky question of defining the term "thread safety" suggerirei che solo poche delle tue classi dovrebbero usare il blocco nella maggior parte delle app.

In genere scrivo molte classi che non cercano di essere esplicitamente thread-safe, ma ugualmente non hanno alcuna dipendenza dal thread. Assumono che se li userai da più thread, lo farai solo da un thread alla volta, con le opportune barriere di memoria per assicurarti che le modifiche apportate in un thread siano visibili in qualunque thread le usi successivamente.

Non ci sono quindi relativamente pochi classi che svolgono il necessario coordinamento.

Ora, è possibile che i problemi con i Contratti di codice rendano queste poche classi sufficientemente deboli da far precipitare tutto il pensiero ... ma non darei per scontato che all'inizio.

Sono un po 'più preoccupato dei problemi che i Contratti di codice si troveranno ad affrontare con il compilatore C# facendo sempre più lavoro di riscrittura del codice ... Non so se il team di Contracts abbia già risolto problemi di blocchi iteratori, ma anche se lo fanno dovranno farlo di nuovo quando C# 5 esce con metodi asincroni ...