]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/latex/wx/mutex.tex
added vendor display name (for consistency with app display name &c) (patch 1831303)
[wxWidgets.git] / docs / latex / wx / mutex.tex
index 5e8275059f51d430997dc001fa0733d4747e2d99..7f455980051972a19666162275480cfba9678278 100644 (file)
@@ -8,10 +8,11 @@ resource as only one thread at a time can own a mutex object.
 Mutexes may be 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 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}.
+thread is waiting) but using them is not recommended under Unix and they are 
+{\bf not} recursive there 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}. On the other hand, Win32 mutexes are
+always recursive.
 
 For example, when several threads use the data stored in the linked list,
 modifications to the list should only be allowed to one thread at a time
@@ -41,7 +42,7 @@ because during a new node addition the list integrity is temporarily broken
         s_mutexProtectingTheGlobalList->Unlock();
     }
 
-    // return true the given number is greater than all array elements
+    // return true if the given number is greater than all array elements
     bool MyThread::IsGreater(int num)
     {
         // before using the list we must acquire the mutex
@@ -86,6 +87,10 @@ None.
 
 <wx/thread.h>
 
+\wxheading{Library}
+
+\helpref{wxBase}{librarieslist}
+
 \wxheading{See also}
 
 \helpref{wxThread}{wxthread}, \helpref{wxCondition}{wxcondition}, 
@@ -93,23 +98,27 @@ None.
 
 \latexignore{\rtfignore{\wxheading{Members}}}
 
+
 \membersection{wxMutex::wxMutex}\label{wxmutexctor}
 
 \func{}{wxMutex}{\param{wxMutexType }{type = {\tt wxMUTEX\_DEFAULT}}}
 
 Default constructor.
 
+
 \membersection{wxMutex::\destruct{wxMutex}}\label{wxmutexdtor}
 
 \func{}{\destruct{wxMutex}}{\void}
 
 Destroys the wxMutex object.
 
+
 \membersection{wxMutex::Lock}\label{wxmutexlock}
 
 \func{wxMutexError}{Lock}{\void}
 
-Locks the mutex object.
+Locks the mutex object. This is equivalent to 
+\helpref{LockTimeout}{wxmutexlocktimeout} with infinite timeout.
 
 \wxheading{Return value}
 
@@ -121,6 +130,25 @@ One of:
 \twocolitem{{\bf wxMUTEX\_DEAD\_LOCK}}{A deadlock situation was detected.}
 \end{twocollist}
 
+
+\membersection{wxMutex::LockTimeout}\label{wxmutexlocktimeout}
+
+\func{wxMutexError}{LockTimeout}{\param{unsigned long}{ msec}}
+
+Try to lock the mutex object during the specified time interval.
+
+\wxheading{Return value}
+
+One of:
+
+\twocolwidtha{7cm}
+\begin{twocollist}\itemsep=0pt
+\twocolitem{{\bf wxMUTEX\_NO\_ERROR}}{Mutex successfully locked.}
+\twocolitem{{\bf wxMUTEX\_TIMEOUT}}{Mutex couldn't be acquired before timeout expiration.}
+\twocolitem{{\bf wxMUTEX\_DEAD\_LOCK}}{A deadlock situation was detected.}
+\end{twocollist}
+
+
 \membersection{wxMutex::TryLock}\label{wxmutextrylock}
 
 \func{wxMutexError}{TryLock}{\void}
@@ -137,6 +165,7 @@ One of:
 \twocolitem{{\bf wxMUTEX\_BUSY}}{The mutex is already locked by another thread.}
 \end{twocollist}
 
+
 \membersection{wxMutex::Unlock}\label{wxmutexunlock}
 
 \func{wxMutexError}{Unlock}{\void}