C26117
Note
This article applies to Visual Studio 2015. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
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);
}
Example
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);
}
}