Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All
Expand Minimize

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.

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);
    }
}
Show:
© 2015 Microsoft