L'utilizzo di IntPtr nel codice gestito potrebbe indicare un problema potenziale di affidabilità e sicurezza. Tutti gli utilizzi ...

L'utilizzo di IntPtr nel codice gestito potrebbe indicare un problema potenziale di affidabilità e sicurezza. Tutti gli utilizzi di IntPtr devono essere controllati per determinare se un SafeHandle (o tecnologia similare) sia richiesto al loro posto. Si verificheranno problemi se IntPtr rappresenta una risorsa nativa (memoria, handle di file, socket, ecc.) che il codice gestito considera propria. Infatti si prevede che il codice gestito rilasci in qualche modo la risorsa causando una perdita di risorse nel caso non vi riesca. In tali scenari si possono verificare problemi di sicurezza e affidabilità anche se è consentito l'accesso multithread a IntPtr e a un elemento che rilasci la risorsa rappresentata da IntPtr. Tali problemi riguardano il riciclo del valore di IntPtr al rilascio della risorsa mentre su un altro thread viene effettuato l'impiego simultaneo della risorsa, causando race condition se un thread può leggere o scrivere dati con la risorsa errata. Ad esempio, se il tipo archivia un handle del sistema operativo come un IntPtr e consente agli utenti di chiamare Close e qualsiasi altro metodo che utilizza l'handle simultaneamente senza alcuna sincronizzazione, il codice presenta un problema di riciclo dell'handle che causa il danneggiamento dei dati e spesso una vulnerabilità di sicurezza. SafeHandle e la classe di pari livello CriticalHandle forniscono un meccanismo per l'incapsulamento di un handle nativo per una risorsa in modo da evitare tali problemi di thread nonché altri problemi come la necessità di controllare con attenzione la durata degli oggetti gestiti che contengono una copia dell'handle nativo nelle chiamate ai metodi nativi, con possibile rimozione delle chiamate a GC.KeepAlive. L'utilizzo di SafeHandle e per aspetti di minor conto CriticalHandle comporta implicitamente un sovraccarico delle prestazioni attenuabile spesso tramite un'attenta progettazione.