- See <xref:Microsoft.VisualStudio.VCProjectEngine.VCLinkerTool.AdditionalOptions%2A>.

The following sample defines a native DLL with one exported function that modifies last error.

}

- See <xref:Microsoft.VisualStudio.VCProjectEngine.VCLinkerTool.OutputFile%2A>.

The following command line compiles and links all C source files in the current directory. The resulting executable file is named PROCESS.exe and is created in the directory "C:\Users\User Name\repos\My Project\bin".

The following command line creates an executable file in `C:\BIN` with the same base name as the first source file in the current directory:

To use **_beginthread** or **_beginthreadex**, the application must link with one of the multithreaded C run-time libraries.

The following example uses **_beginthread** and **_endthread**.

The `_Guarded_by_` annotation in the code specifies the lock to use to guard a shared variable. Warning C26100 is generated when the guard contract is violated.

The following example generates warning C26100 because there is a violation of the `_Guarded_by_` contract.

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.

}

Warning C26130 is issued when the analyzer detects a potential race condition but infers that the function is likely to be run in a single threaded mode, for example, when the function is in the initialization stage based on certain heuristics.

In the following example, warning C26130 is generated because a `_Guarded_by_` member is being modified without a lock.

}

Alternatively, you can annotate a code fragment by using `_No_competing_thread_begin_` and `_No_competing_thread_end_`, as follows.

Warning C26135 is issued when the analyzer infers that a function is a lock wrapper function that has a lock acquire or lock release side effect. If the code is not intended to be a wrapper function, then either the lock is leaking (if the lock is being acquired) or it is being released incorrectly (if the lock is being released).

The following example generates warning C26135 because an appropriate side effect annotation is missing.

}

Warning C26138 warns when a coroutine is suspended while holding a lock. In general, we can't know how long will a coroutine remain in the suspended state so this pattern may result in longer critical sections than expected.

The following code will generate C26138.

}

Warning C26160 resembles warning [C26110](../code-quality/c26110.md) except that the confidence level is lower. For example, the function may contain annotation errors.

The following code generates warning C26160.

};