C26117
warning C26117: Releasing unheld lock <lock> in function <func>.
Enforcement of syntactically scoped lock acquire and lock release pairs in C/C++ programs is not performed by the language. A function may introduce a locking side effect by making an observable modification to the concurrency state. For example, a lock wrapper function increments the number of lock acquisitions, or lock count, for a given lock.You can annotate a function that has a side effect from a lock acquire or lock release by using _Acquires_lock_ or _Releases_lock_, respectively. Without such annotations, a function is expected not to change any lock count after it returns. If acquires and releases are not balanced, they are considered to be orphaned. Warning C26117 is issued when a function that has not been annotated with _Releases_lock_ releases a lock that it doesn't hold, because the function must own the lock before it releases it.
Example
The following example generates warning C26117 because the function ReleaseUnheldLock releases a lock that it doesn't necessarily hold—the state of flag is ambiguous—and there is no annotation that specifies that it should.
typedef struct _DATA
{
CRITICAL_SECTION cs;
} DATA;
int flag;
void ReleaseUnheldLock(DATA* p)
{
if (flag)
EnterCriticalSection(&p->cs);
// code ...
LeaveCriticalSection(&p->cs);
}
The following code fixes the problem by guaranteeing that the released lock is also acquired under the same conditions.
typedef struct _DATA
{
CRITICAL_SECTION cs;
} DATA;
int flag;
void ReleaseUnheldLock(DATA* p)
{
if (flag)
{
EnterCriticalSection(&p->cs);
// code ...
LeaveCriticalSection(&p->cs);
}
}