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}).
\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}