Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updated recursive mutexes description

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@21981 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
2003-07-14 23:35:28 +00:00
parent 59d21254e8
commit dc65f4ff28
1 changed files with 23 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/latex/wx/mutex.tex
View File

@@ -3,11 +3,15 @@
A mutex object is a synchronization object whose state is set to signaled when A mutex object is a synchronization object whose state is set to signaled when
it is not owned by any thread, and nonsignaled when it is owned. Its name comes it is not owned by any thread, and nonsignaled when it is owned. Its name comes
from its usefulness in coordinating mutually-exclusive access to a shared from its usefulness in coordinating mutually-exclusive access to a shared
resource. Only one thread at a time can own a mutex object but the mutexes are resource as only one thread at a time can own a mutex object.
recursive in the sense that a thread can lock a mutex which it had already
locked before (instead of dead locking the entire process in this situation by Mutexes may be recursive in the sense that a thread can lock a mutex which it
starting to wait on a mutex which will never be released while the thread is had already locked before (instead of dead locking the entire process in this
waiting). situation by starting to wait on a mutex which will never be released while the
thread is waiting) but using them is not recommended and they are {\bf not}
recursive by default. The reason for this is that recursive mutexes are not
supported by all Unix flavours and, worse, they cannot be used with
\helpref{wxCondition}{wxcondition}.
For example, when several thread use the data stored in the linked list, For example, when several thread use the data stored in the linked list,
modifications to the list should be only allowed to one thread at a time modifications to the list should be only allowed to one thread at a time
@@ -61,6 +65,19 @@ mutex is unlocked in any case: whether the function returns true or false
this class instead of directly using wxMutex is, in general safer and is even this class instead of directly using wxMutex is, in general safer and is even
more so if your program uses C++ exceptions. more so if your program uses C++ exceptions.
\wxheading{Constants}
\begin{verbatim}
enum wxMutexType
{
// normal mutex: try to always use this one
wxMUTEX_DEFAULT,
// recursive mutex: don't use these ones with wxCondition
wxMUTEX_RECURSIVE
};
\end{verbatim}
\wxheading{Derived from} \wxheading{Derived from}
None. None.
@@ -78,7 +95,7 @@ None.
\membersection{wxMutex::wxMutex}\label{wxmutexconstr} \membersection{wxMutex::wxMutex}\label{wxmutexconstr}
\func{}{wxMutex}{\void} \func{}{wxMutex}{\param{wxMutexType }{type = {\tt wxMUTEX\_DEFAULT}}}
Default constructor. Default constructor.