|
Overview |
|
|
|
Group |
|
|
|
Quick Info
Windows NT
| Yes
| Win95
| Yes
| Win32s
| No
| Import Library
| kernel32.lib
| Header File
| winbase.h
| Unicode
| WinNT
| Platform Notes
| None
|
|
|
CreateMutex
The
CreateMutex function creates a named or unnamed mutex object.
HANDLE CreateMutex(
LPSECURITY_ATTRIBUTES lpMutexAttributes,
| // pointer to security attributes
|
BOOL bInitialOwner,
| // flag for initial ownership
|
LPCTSTR lpName
| // pointer to mutex-object name
|
);
|
|
Parameters
lpMutexAttributes
Pointer to a
SECURITY_ATTRIBUTES structure that determines whether the returned handle can be inherited by
child processes. If
lpMutexAttributes is NULL, the handle cannot be inherited.
Windows NT: The
lpSecurityDescriptor member of the structure specifies a security descriptor for the new mutex. If
lpMutexAttributes is NULL, the mutex gets a default security descriptor.
Windows 95: The
lpSecurityDescriptor member of the structure is ignored.
bInitialOwner
Specifies the initial owner of the mutex object. If TRUE, the calling thread
requests immediate ownership of the mutex object. Otherwise, the mutex is not
owned.
lpName
Points 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 matches the name of an existing named mutex object, this function requests
MUTEX_ALL_ACCESS access to the existing object. In this case, the
bInitialOwner parameter is ignored because it has already been set by the creating process.
If the
lpMutexAttributes parameter is not NULL, it determines whether the handle can be inherited, but
its security-descriptor member is ignored.
If
lpName is NULL, the mutex object is created without a name.
If
lpName matches the name of an existing event, semaphore, or file-mapping object, the
function fails and the
GetLastError function returns ERROR_INVALID_HANDLE. This occurs because event, mutex,
semaphore, and file-mapping objects share the same name space.
Return Values
If the function succeeds, the return value is a handle to the mutex object. If
the named mutex object existed before the function call, the
GetLastError function returns ERROR_ALREADY_EXISTS. Otherwise,
GetLastError returns zero.
If the function fails, the return value is NULL. 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 it is not owned by any thread.
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, you 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 the user of
the responsibility of ensuring that the creating process is started first. When
using this technique, you should 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. The following object-sharing
mechanisms are available:
- A child process created by the CreateProcess function can inherit a handle to a mutex object if the lpMutexAttributes parameter of CreateMutex enabled inheritance.
- A process can specify the mutex-object handle in a call to the DuplicateHandle function to create a duplicate handle that can be used by another process.
- A process can specify the name of a mutex object in a call to the OpenMutex or 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.
See Also
CloseHandle,
CreateProcess,
DuplicateHandle,
OpenMutex,
ReleaseMutex,
SECURITY_ATTRIBUTES
- Software for developers
-
Delphi Components
.Net Components
Software for Android Developers
- More information resources
-
MegaDetailed.Net
Unix Manual Pages
Delphi Examples
- Databases for Amazon shops developers
-
Amazon Categories Database
Browse Nodes Database