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,
-modifications to the list should be only allowed to one thread at a time
+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
because during a new node addition the list integrity is temporarily broken
(this is also called {\it program invariant}).
\latexignore{\rtfignore{\wxheading{Members}}}
-\membersection{wxMutex::wxMutex}\label{wxmutexconstr}
+\membersection{wxMutex::wxMutex}\label{wxmutexctor}
\func{}{wxMutex}{\param{wxMutexType }{type = {\tt wxMUTEX\_DEFAULT}}}
Default constructor.
-\membersection{wxMutex::\destruct{wxMutex}}
+\membersection{wxMutex::\destruct{wxMutex}}\label{wxmutexdtor}
\func{}{\destruct{wxMutex}}{\void}
\begin{twocollist}\itemsep=0pt
\twocolitem{{\bf wxMUTEX\_NO\_ERROR}}{There was no error.}
\twocolitem{{\bf wxMUTEX\_DEAD\_LOCK}}{A deadlock situation was detected.}
-\twocolitem{{\bf wxMUTEX\_BUSY}}{The mutex is already locked by another thread.}
\end{twocollist}
\membersection{wxMutex::TryLock}\label{wxmutextrylock}
\twocolwidtha{7cm}
\begin{twocollist}\itemsep=0pt
\twocolitem{{\bf wxMUTEX\_NO\_ERROR}}{There was no error.}
-\twocolitem{{\bf wxMUTEX\_DEAD\_LOCK}}{A deadlock situation was detected.}
\twocolitem{{\bf wxMUTEX\_BUSY}}{The mutex is already locked by another thread.}
\end{twocollist}
\twocolwidtha{7cm}
\begin{twocollist}\itemsep=0pt
\twocolitem{{\bf wxMUTEX\_NO\_ERROR}}{There was no error.}
-\twocolitem{{\bf wxMUTEX\_DEAD\_LOCK}}{A deadlock situation was detected.}
-\twocolitem{{\bf wxMUTEX\_BUSY}}{The mutex is already locked by another thread.}
-\twocolitem{{\bf wxMUTEX\_UNLOCKED}}{The calling thread tries to unlock an unlocked mutex.}
+\twocolitem{{\bf wxMUTEX\_UNLOCKED}}{The calling thread doesn't own the mutex.}
\end{twocollist}