Avertissement C26117

Libération du verrou non retenu « lock » dans la fonction « func ».

L’application des paires d’acquisitions et de mise en production de verrous de portée syntactique dans les programmes C/C++ n’est pas effectuée par le langage. Une fonction peut introduire un effet secondaire de verrouillage en apportant une modification observable à l’état d’accès concurrentiel. Par exemple, une fonction wrapper de verrou incrémente le nombre d’acquisitions de verrous ou le nombre de verrous pour un verrou donné. Vous pouvez annoter une fonction qui a un effet secondaire à partir d’une libération de verrou ou d’acquisition de verrou à l’aide _Acquires_lock_ ou _Releases_lock_, respectivement. Sans ces annotations, une fonction est censée ne pas modifier le nombre de verrous après son retour. Si les acquisitions et versions ne sont pas équilibrées, elles sont considérées comme orphelines. Avertissement C26117 est émis lorsqu’une fonction qui n’a pas été annotée avec _Releases_lock_ libère un verrou qu’il ne contient pas, car la fonction doit posséder le verrou avant de le libérer.

Exemples

L’exemple suivant génère l’avertissement C26117, car la fonction ReleaseUnheldLock libère un verrou qu’elle ne contient pas nécessairement ( l’état est flag ambigu et il n’y a pas d’annotation qui spécifie qu’elle doit.

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 garantissant que le verrou libéré est également acquis 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

• C26115