C26117

The new home for Visual Studio documentation is Visual Studio 2017 Documentation on docs.microsoft.com.

The latest version of this topic can be found at 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);  
    }  
}  

C26115