CreateMutex (Compact 2013)
3/28/2014
This function creates a named or unnamed mutex object.
Syntax
HANDLE CreateMutex(
LPSECURITY_ATTRIBUTES lpMutexAttributes,
BOOL bInitialOwner,
LPCTSTR lpName
);
Parameters
- lpMutexAttributes
[in] Ignored. Must be NULL.
- bInitialOwner
[in] Boolean that specifies the initial owner of the mutex object. If this value is TRUE and the caller created the mutex, the calling thread obtains ownership of the mutex object. Otherwise, the calling thread does not obtain ownership of the mutex. To determine if the caller created the mutex, see the Return Values section.
lpName
[in] Long pointer to a null-terminated string specifying the name of the mutex object. The name is limited to MAX_PATH characters and can contain any character except the backslash path-separator character (\). Name comparison is case sensitive.If lpName is NULL, the mutex object is created without a name.
If lpName matches the name of an existing named mutex object, the bInitialOwner parameter is ignored because it has already been set by the creation process.
Each object type, such as memory maps, semaphores, events, message queues, mutexes, and watchdog timers, has its own separate namespace. Empty strings ("") are handled as named objects. On Windows desktop-based platforms, synchronization objects all share the same namespace.
Return Value
A handle to the mutex object indicates success. If the named mutex object existed before the function call, the function returns a handle to the existing object, and GetLastError returns ERROR_ALREADY_EXISTS. Otherwise, the caller created the mutex.
NULL indicates failure. To get extended error information, call GetLastError.
Remarks
The handle returned by CreateMutex has MUTEX_ALL_ACCESS access to the new mutex object and can be used in any function that requires a handle to a mutex object.
Any thread of the calling process can specify the mutex-object handle in a call to one of the wait functions. The single-object wait functions return when the state of the specified object is signaled. The multiple-object wait functions can be instructed to return either when any one or when all of the specified objects are signaled. When a wait function returns, the waiting thread is released to continue its execution.
The state of a mutex object is signaled when no thread owns it. The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns. Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership.
The thread that owns a mutex can specify the same mutex in repeated wait function calls without blocking its execution. Typically, the thread would not wait repeatedly for the same mutex, but this mechanism prevents a thread from deadlocking itself while waiting for a mutex that it already owns. However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait.
Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving you of the responsibility of ensuring that the creating process is started first. When using this technique, set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.
Multiple processes can have handles of the same mutex object, enabling use of the object for interprocess synchronization. To provide object sharing, a process can specify the name of a mutex object in a call to the CreateMutex function.
Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.
Note
Do not put protected information into the names of kernel objects such as events, semaphores, mutexes, or memory-mapped files because CeLog writes these to its log. A malicious user could collect this information from the log.
Note
Do not take a pointer from a caller and use it as the name of a kernel object without first using access-checking APIs such as CeOpenCallerBuffer, which are designed to prevent callers from reading system data.
Requirements
Header |
winbase.h |
Library |
coredll.lib, |
See Also
Reference
Synchronization Functions
CreateProcess
ReleaseMutex