Mutex
(mutual exclusion) is a memory structure that allows
multiple program threads to share the same resource, such as file access - but not simultaneously. When a
program is started, a mutex is created with a unique name. After this stage,
any thread that needs the resource must lock the mutex from other threads while it is using
the resource. The mutex is set to unlock when the data is no longer needed or
the routine is finished.
Suppose a section of code is altering piece of data, while another thread, triggered by some unpredictable event, starts executing. If second thread reads from the same piece of data, the data, in the process of being overwritten, is in inconsistent and unpredictable state. If the second state tries overwriting the data, the ensuing state will probably be unrecoverable. These sections of code accessing shared data must therefore be protected, so that other processes which read from or write to the chunk of data are excluded from running.
The
following table lists mutex functions and the actions they perform.
|
Initialization
Mutexes are either intra-process or inter-process,
depending upon the argument passed implicitly or explicitly to the
initialization of that mutex. A statically allocated mutex does not need to be
explicitly initialized; by default, a statically allocated mutex is initialized
with all zeros and its scope is set to be within the calling process.
For
inter-process synchronization, a mutex needs to be allocated in memory shared
between these processes. Since the memory for such a mutex must be allocated
dynamically, the mutex needs to be explicitly initialized with the appropriate
attribute that indicates inter-process use.
Locking
and Unlocking
A critical section of code is enclosed by a call to
lock the mutex and the call to unlock the mutex to protect it from simultaneous
access by multiple threads. Only one thread at a time may possess mutually
exclusive access to the critical section of code that is enclosed by the
mutex-locking call and the mutex-unlocking call, whether the mutex's scope is
intra-process or inter-process. A thread calling to lock the mutex either gets
exclusive access to the code starting from the successful locking until its
call to unlock the mutex, or it waits until the mutex is unlocked by the thread
that locked it.
Mutexes
have ownership, unlike semaphores. Only the thread that locked a mutex, (that
is, the owner of the mutex), should unlock it.
If
a thread waiting for a mutex receives a signal, upon return from the signal
handler, the thread resumes waiting for the mutex as if there was no interrupt.
Caveats
Mutexes are almost like data – they can be embedded
in data structures, files, dynamic or static memory, and so forth. Hence, they
are easy to introduce into a program. However, too many mutexes can degrade
performance and scalability of the application. Because too few mutexes can
hinder the concurrency of the application, they should be introduced with care.
Also, incorrect usage (such as recursive calls, or violation of locking order,
and so forth) can lead to deadlocks, or worse, data inconsistencies.
Lucky 15 Casino: Get your bonus today - Goyang
ReplyDeleteLucky 15 Casino is a new and 부평바카라 exciting place to be located in the heart 탱글다희영구정지 of 슬롯 나라 Western Washington. We aim to help 바카라 시스템 배팅 you get bet the ultimate in Las Vegas gaming experience!