C26117
Advertencia C26117: liberar el bloqueo <lock> sin mantenerlo en la función <func>.
El ámbito de cumplimiento del bloqueo sintáctico adquirir y el bloqueo versión en pares en programas de C/C++ no lo realiza el lenguaje.Una función puede producir un efecto secundario de bloqueo creando una modificación observable al estado de simultaneidad.Por ejemplo, una función contenedora de bloqueo aumenta el número de adquisiciones de bloqueo, o el recuento de bloqueo, para un bloqueo determinado. Puede anotar una función que tenga un efecto secundario de un bloqueo adquirido o un bloqueo liberado mediante _Acquires_lock_ o _Releases_lock_, respectivamente.Sin estas anotaciones, se espera que una función no cambie ningún recuento de bloqueos después de que vuelva.Si las adquisiciones y las liberaciones no están equilibradas, se consideran huérfanas.La advertencia C26117 se emite cuando una función que no se ha anotado con _Releases_lock_ libera un bloqueo que no se mantiene, porque la función debe ser propietaria del bloqueo antes de liberarlo.
Ejemplo
El ejemplo siguiente genera la advertencia C26117 porque la función ReleaseUnheldLock libera un bloqueo que no posee necesariamente - el estado de flag es ambiguo - y no hay ninguna anotación que lo especifique.
typedef struct _DATA
{
CRITICAL_SECTION cs;
} DATA;
int flag;
void ReleaseUnheldLock(DATA* p)
{
if (flag)
EnterCriticalSection(&p->cs);
// code ...
LeaveCriticalSection(&p->cs);
}
El siguiente código corrige el problema garantizando que el bloqueo liberado también se adquiera en las mismas condiciones.
typedef struct _DATA
{
CRITICAL_SECTION cs;
} DATA;
int flag;
void ReleaseUnheldLock(DATA* p)
{
if (flag)
{
EnterCriticalSection(&p->cs);
// code ...
LeaveCriticalSection(&p->cs);
}
}