Partager via


C26117

avertissement C26117 : Libère le verrou <verrou> dans la fonction <fonc>.

La mise en place d'un verrou à portée limitée syntaxiquement obtient et verrouille libére les paires dans des applications C/C++ n'est pas effectué par le langage.Une fonction peut introduire un effet secondaire verrouillant en apportant une modification observable à l'état d'accès concurrentiel.Par exemple, une fonction de verrou englobante incrémente le nombre d'entrées de verrou, ou le nombre de verrous, pour un verrou fourni. Vous pouvez annoter une fonction qui a comme effet secondaire d'acquérir un verrou ou de le libérer à l'aide respectivement de _Acquires_lock_ et de _Releases_lock_.Sans de telles annotations, il est prévu qu'une fonction ne modifie pas le nombre de verrous après qu'elle soit retourner.Si l'acquisition et la libération ne sont pas équilibrées, elles sont considérées comme orpheline.Avertissement C26117 est émis lorsque une fonction qui n'était pas annotée avec _Releases_lock_ libère un verrou qu'il ne détient pas, car la fonction doit posséder le verrou avant de le libérer.

Exemple

L'exemple suivant génère un avertissement C26117 car la fonction ReleaseUnheldLock libère un verrou qui n'est pas nécessairement en état de blocage - l'état de flag est ambigu- et il n'y a pas d'annotation qui spécifie qu'il doit l'être.

typedef struct _DATA 
{
    CRITICAL_SECTION cs;
} DATA;

int flag;

void ReleaseUnheldLock(DATA* p)
{
    if (flag)
        EnterCriticalSection(&p->cs);
    // code ...
    LeaveCriticalSection(&p->cs);
}

Le code suivant résout le problème en vérifiant que le verrou relaché est acquit dans les mêmes conditions.

typedef struct _DATA 
{
    CRITICAL_SECTION cs;
} DATA;

int flag;

void ReleaseUnheldLock(DATA* p)
{
    if (flag)
    {
        EnterCriticalSection(&p->cs);
        // code ...
        LeaveCriticalSection(&p->cs);
    }
}

Voir aussi

Référence

C26115