multithreaded (MT) programs: the \helpref{thread}{wxthread} class itself and different
synchronization objects: \helpref{mutexes}{wxmutex} and
\helpref{critical sections}{wxcriticalsection} with
-\helpref{conditions}{wxcondition}.
+\helpref{conditions}{wxcondition}. The thread API in wxWindows resembles to
+POSIX1.c threads API (a.k.a. pthreads), although several functions have
+different names and some features inspired by Win32 thread API are there as
+well.
These classes will hopefully make writing MT programs easier and they also
provide some extra error checking (compared to the native (be it Win32 or Posix)
(example: launching a separate thread when doing a long computation to show a
progress dialog). Other implementation choices are available: for the progress
dialog example it is far better to do the calculations in the
-\helpref{idle handler}{wxidleevent} or call \helpref{wxYield()}{wxyield}
+\helpref{idle handler}{wxidleevent} or call \helpref{wxYield()}{wxyield}
periodically to update the screen.
If you do decide to use threads in your application, it is strongly recommended
Win32 a thread can only access GDI objects such as pens, brushes, \&c created by
itself and not by the other threads).
-Final note: in the current release of wxWindows, there are no specific
-facilities for communicating between the threads. However, the usual
-\helpref{ProcessEvent()}{wxevthandlerprocessevent} function may be used for
-thread communication too - but you should provide your own synchronisation
-mechanism if you use it (e.g. just use a critical section before sending a
-message) because there is no built-in synchronisation.
+For communication between threads, use
+\helpref{wxEvtHandler::AddPendingEvent}{wxevthandleraddpendingevent}
+or its short version \helpref{wxPostEvent}{wxpostevent}. These functions
+have thread safe implementation so that they can be used as they are for
+sending event from one thread to another.
+
+