1 /////////////////////////////////////////////////////////////////////////////
3 // Purpose: interface of all thread-related wxWidgets classes
4 // Author: wxWidgets team
6 // Licence: wxWindows license
7 /////////////////////////////////////////////////////////////////////////////
10 /** See wxCondition. */
15 wxCOND_TIMEOUT
, //!< WaitTimeout() has timed out
23 wxCondition variables correspond to pthread conditions or to Win32 event objects.
24 They may be used in a multithreaded application to wait until the given condition
25 becomes @true which happens when the condition becomes signaled.
27 For example, if a worker thread is doing some long task and another thread has
28 to wait until it is finished, the latter thread will wait on the condition
29 object and the worker thread will signal it on exit (this example is not
30 perfect because in this particular case it would be much better to just
31 wxThread::Wait for the worker thread, but if there are several worker threads
32 it already makes much more sense).
34 Note that a call to wxCondition::Signal may happen before the other thread calls
35 wxCondition::Wait and, just as with the pthread conditions, the signal is then
36 lost and so if you want to be sure that you don't miss it you must keep the
37 mutex associated with the condition initially locked and lock it again before calling
38 wxCondition::Signal. Of course, this means that this call is going to block
39 until wxCondition::Wait is called by another thread.
41 @section condition_example Example
43 This example shows how a main thread may launch a worker thread which starts
44 running and then waits until the main thread signals it to continue:
47 class MySignallingThread : public wxThread
50 MySignallingThread(wxMutex *mutex, wxCondition *condition)
53 m_condition = condition;
58 virtual ExitCode Entry()
62 // tell the other(s) thread(s) that we're about to terminate: we must
63 // lock the mutex first or we might signal the condition before the
64 // waiting threads start waiting on it!
65 wxMutexLocker lock(*m_mutex);
66 m_condition->Broadcast(); // same as Signal() here -- one waiter only
72 wxCondition *m_condition;
79 wxCondition condition(mutex);
81 // the mutex should be initially locked
84 // create and run the thread but notice that it won't be able to
85 // exit (and signal its exit) before we unlock the mutex below
86 MySignallingThread *thread = new MySignallingThread(&mutex, &condition);
90 // wait for the thread termination: Wait() atomically unlocks the mutex
91 // which allows the thread to continue and starts waiting
99 Of course, here it would be much better to simply use a joinable thread and
100 call wxThread::Wait on it, but this example does illustrate the importance of
101 properly locking the mutex when using wxCondition.
106 @see wxThread, wxMutex
112 Default and only constructor.
113 The @a mutex must be locked by the caller before calling Wait() function.
114 Use IsOk() to check if the object was successfully initialized.
116 wxCondition(wxMutex
& mutex
);
119 Destroys the wxCondition object.
121 The destructor is not virtual so this class should not be used polymorphically.
126 Broadcasts to all waiting threads, waking all of them up.
128 Note that this method may be called whether the mutex associated with
129 this condition is locked or not.
133 wxCondError
Broadcast();
136 Returns @true if the object had been initialized successfully, @false
137 if an error occurred.
142 Signals the object waking up at most one thread.
144 If several threads are waiting on the same condition, the exact thread
145 which is woken up is undefined. If no threads are waiting, the signal is
146 lost and the condition would have to be signalled again to wake up any
147 thread which may start waiting on it later.
149 Note that this method may be called whether the mutex associated with this
150 condition is locked or not.
154 wxCondError
Signal();
157 Waits until the condition is signalled.
159 This method atomically releases the lock on the mutex associated with this
160 condition (this is why it must be locked prior to calling Wait()) and puts the
161 thread to sleep until Signal() or Broadcast() is called.
162 It then locks the mutex again and returns.
164 Note that even if Signal() had been called before Wait() without waking
165 up any thread, the thread would still wait for another one and so it is
166 important to ensure that the condition will be signalled after
167 Wait() or the thread may sleep forever.
169 @return Returns wxCOND_NO_ERROR on success, another value if an error occurred.
176 Waits until the condition is signalled or the timeout has elapsed.
178 This method is identical to Wait() except that it returns, with the
179 return code of @c wxCOND_TIMEOUT as soon as the given timeout expires.
182 Timeout in milliseconds
184 @return Returns wxCOND_NO_ERROR if the condition was signalled,
185 wxCOND_TIMEOUT if the timeout elapsed before this happened or
186 another error code from wxCondError enum.
188 wxCondError
WaitTimeout(unsigned long milliseconds
);
193 @class wxCriticalSectionLocker
195 This is a small helper class to be used with wxCriticalSection objects.
197 A wxCriticalSectionLocker enters the critical section in the constructor and
198 leaves it in the destructor making it much more difficult to forget to leave
199 a critical section (which, in general, will lead to serious and difficult
207 // gs_critSect is some (global) critical section guarding access to the
209 wxCriticalSectionLocker locker(gs_critSect);
226 Without wxCriticalSectionLocker, you would need to remember to manually leave
227 the critical section before each @c return.
232 @see wxCriticalSection, wxMutexLocker
234 class wxCriticalSectionLocker
238 Constructs a wxCriticalSectionLocker object associated with given
239 @a criticalsection and enters it.
241 wxCriticalSectionLocker(wxCriticalSection
& criticalsection
);
244 Destructor leaves the critical section.
246 ~wxCriticalSectionLocker();
252 @class wxThreadHelper
254 The wxThreadHelper class is a mix-in class that manages a single background
255 thread, either detached or joinable (see wxThread for the differences).
256 By deriving from wxThreadHelper, a class can implement the thread
257 code in its own wxThreadHelper::Entry() method and easily share data and
258 synchronization objects between the main thread and the worker thread.
260 Doing this prevents the awkward passing of pointers that is needed when the
261 original object in the main thread needs to synchronize with its worker thread
262 in its own wxThread derived object.
264 For example, wxFrame may need to make some calculations in a background thread
265 and then display the results of those calculations in the main window.
267 Ordinarily, a wxThread derived object would be created with the calculation
268 code implemented in wxThread::Entry. To access the inputs to the calculation,
269 the frame object would often need to pass a pointer to itself to the thread object.
270 Similarly, the frame object would hold a pointer to the thread object.
272 Shared data and synchronization objects could be stored in either object
273 though the object without the data would have to access the data through
275 However with wxThreadHelper the frame object and the thread object are
276 treated as the same object. Shared data and synchronization variables are
277 stored in the single object, eliminating a layer of indirection and the
282 class MyFrame : public wxFrame, public wxThreadHelper
285 MyFrame() : wxThreadHelper(wxTHREAD_JOINABLE) {}
289 virtual ExitCode Entry()
291 // here we do our long task, periodically calling TestDestroy():
292 while (!TestDestroy())
294 // ...do another bit of work here...
296 // post an update message to the frame
299 // TestDestroy() returned true (which means the main thread
300 // asked us to terminate as soon as possible) or we ended the
307 // important: before terminating, we _must_ wait for our
308 // joinable thread to end, if it's running!
309 if (GetThread()->IsRunning())
314 void DoStartALongTask();
318 void MyFrame::DoStartALongTask()
320 // we want to start a long task, but we don't want our GUI to block
321 // while it's executed, so we use a thread to do it.
322 if (Create() != wxTHREAD_NO_ERROR)
324 wxLogError("Could not create the worker thread!");
329 if (Run() != wxTHREAD_NO_ERROR)
331 wxLogError("Could not run the worker thread!");
346 This constructor simply initializes internal member variables and tells
347 wxThreadHelper which type the thread internally managed should be.
349 wxThreadHelper(wxThreadKind kind
= wxTHREAD_JOINABLE
);
352 The destructor frees the resources associated with the thread, forcing
353 it to terminate (it uses wxThread::Kill function).
355 Because of the wxThread::Kill unsafety, you should always wait
356 (with wxThread::Wait) for joinable threads to end or call wxThread::Delete
357 on detached threads, instead of relying on this destructor for stopping
360 virtual ~wxThreadHelper();
363 This is the entry point of the thread.
365 This function is pure virtual and must be implemented by any derived class.
366 The thread execution will start here.
368 The returned value is the thread exit code which is only useful for
369 joinable threads and is the value returned by @c "GetThread()->Wait()".
371 This function is called by wxWidgets itself and should never be called
374 virtual ExitCode
Entry() = 0;
377 Creates a new thread.
379 The thread object is created in the suspended state, and you
380 should call @ref wxThread::Run "GetThread()->Run()" to start running it.
382 You may optionally specify the stack size to be allocated to it (ignored
383 on platforms that don't support setting it explicitly, eg. Unix).
385 Note that the type of the thread which is created is defined in the
388 @return One of the ::wxThreadError enum values.
390 wxThreadError
Create(unsigned int stackSize
= 0);
393 This is a public function that returns the wxThread object associated with
396 wxThread
* GetThread() const;
400 Possible critical section types
403 enum wxCriticalSectionType
406 /** Recursive critical section under both Windows and Unix */
408 wxCRITSEC_NON_RECURSIVE
409 /** Non-recursive critical section under Unix, recursive under Windows */
413 @class wxCriticalSection
415 A critical section object is used for exactly the same purpose as a wxMutex.
416 The only difference is that under Windows platform critical sections are only
417 visible inside one process, while mutexes may be shared among processes,
418 so using critical sections is slightly more efficient.
420 The terminology is also slightly different: mutex may be locked (or acquired)
421 and unlocked (or released) while critical section is entered and left by the program.
423 Finally, you should try to use wxCriticalSectionLocker class whenever
424 possible instead of directly using wxCriticalSection for the same reasons
425 wxMutexLocker is preferrable to wxMutex - please see wxMutex for an example.
430 @see wxThread, wxCondition, wxCriticalSectionLocker
432 class wxCriticalSection
436 Default constructor initializes critical section object.
437 By default critical sections are recursive under Unix and Windows.
439 wxCriticalSection( wxCriticalSectionType critSecType
= wxCRITSEC_DEFAULT
);
442 Destructor frees the resources.
444 ~wxCriticalSection();
447 Enter the critical section (same as locking a mutex).
449 There is no error return for this function.
450 After entering the critical section protecting some global
451 data the thread running in critical section may safely use/modify it.
456 Leave the critical section allowing other threads use the global data
457 protected by it. There is no error return for this function.
463 The possible thread kinds.
467 /** Detached thread */
470 /** Joinable thread */
475 The possible thread errors.
480 wxTHREAD_NO_ERROR
= 0,
482 /** No resource left to create a new thread. */
483 wxTHREAD_NO_RESOURCE
,
485 /** The thread is already running. */
488 /** The thread isn't running. */
489 wxTHREAD_NOT_RUNNING
,
491 /** Thread we waited for had to be killed. */
494 /** Some other error */
499 Defines the interval of priority
503 WXTHREAD_MIN_PRIORITY
= 0u,
504 WXTHREAD_DEFAULT_PRIORITY
= 50u,
505 WXTHREAD_MAX_PRIORITY
= 100u
512 A thread is basically a path of execution through a program.
513 Threads are sometimes called @e light-weight processes, but the fundamental difference
514 between threads and processes is that memory spaces of different processes are
515 separated while all threads share the same address space.
517 While it makes it much easier to share common data between several threads, it
518 also makes it much easier to shoot oneself in the foot, so careful use of
519 synchronization objects such as mutexes (see wxMutex) or critical sections
520 (see wxCriticalSection) is recommended.
521 In addition, don't create global thread objects because they allocate memory
522 in their constructor, which will cause problems for the memory checking system.
525 @section thread_types Types of wxThreads
527 There are two types of threads in wxWidgets: @e detached and @e joinable,
528 modeled after the the POSIX thread API. This is different from the Win32 API
529 where all threads are joinable.
531 By default wxThreads in wxWidgets use the @b detached behavior.
532 Detached threads delete themselves once they have completed, either by themselves
533 when they complete processing or through a call to Delete(), and thus
534 @b must be created on the heap (through the new operator, for example).
536 Typically you'll want to store the instances of the detached wxThreads you
537 allocate, so that you can call functions on them.
538 Because of their nature however you'll need to always use a critical section
542 // declare a new type of event, to be used by our MyThread class:
543 extern const wxEventType wxEVT_COMMAND_MYTHREAD_COMPLETED;
545 class MyThread : public wxThread
548 MyThread(wxEvtHandler *handler) : wxThread(wxTHREAD_DETACHED)
549 { m_pHandler = handler; }
553 while (!TestDestroy())
555 // ... do a bit of work...
558 // signal the event handler that this thread is going to be destroyed
559 // NOTE: here we assume that using the m_pHandler pointer is safe,
560 // (in this case it's assured by the MyFrame destructor)
561 wxQueueEvent(m_pHandler, new wxCommandEvent(wxEVT_COMMAND_MYTHREAD_COMPLETED));
563 return (ExitCode)0; // success
566 wxEvtHandler *m_pHandler;
569 class MyFrame : public wxFrame
575 void DoStartThread();
576 void DoPauseThread();
578 // a resume routine would be mostly identic to DoPauseThread()
579 void DoResumeThread() { ... }
581 void OnThreadExit(wxCommandEvent&);
586 // this is _required_ for writing safe code!
587 wxCriticalSection m_critSection;
590 void MyFrame::DoStartThread()
592 m_pThread = new wxThread();
594 if ( m_pThread->Create() != wxTHREAD_NO_ERROR )
596 wxLogError("Can't create the thread!");
602 if (m_pThread->Run() != wxTHREAD_NO_ERROR )
604 wxLogError("Can't create the thread!");
609 // after the call to wxThread::Run(), the m_pThread pointer is "unsafe":
610 // at any moment the thread may cease to exist (because it completes its work).
611 // To avoid dangling pointers OnThreadExit() will set m_pThread
612 // to NULL when the thread dies.
616 void MyFrame::OnThreadExit(wxCommandEvent&)
618 // the thread just ended; make sure not to leave dangling pointers around
622 void MyFrame::DoPauseThread()
624 // anytime we access the m_pThread pointer we must ensure that it won't
625 // be modified in the meanwhile; inside a critical section we are sure
626 // that we are the only thread running, so that's what we need.
627 wxCriticalSectionLocker enter(m_critSection);
629 if (m_pThread) // does the thread still exist?
631 // without a critical section, once reached this point it may happen
632 // that the OS scheduler gives control to the MyThread::Entry() function,
633 // which in turn may return (because it completes its work) making
634 // invalid the m_pThread pointer; the critical section above
635 // makes this code safe.
637 if (m_pThread->Pause() != wxTHREAD_NO_ERROR )
638 wxLogError("Can't pause the thread!");
644 wxCriticalSectionLocker enter(m_critSection);
646 if (m_pThread) // does the thread still exist?
648 if (m_pThread->Delete() != wxTHREAD_NO_ERROR )
649 wxLogError("Can't delete the thread!");
651 // as soon as we exit the critical section and the MyThread::Entry
652 // function calls TestDestroy(), the thread will exit and thus
653 // call OnExitThread(); we need to maintain MyFrame object alive
655 wxEventLoopBase* p = wxEventLoopBase::GetActive();
656 while (p->Pending() && m_pThread)
659 // the wxEVT_COMMAND_MYTHREAD_COMPLETED event was posted, we can
665 Conversely, @b joinable threads do not delete themselves when they are done
666 processing and as such are safe to create on the stack. Joinable threads
667 also provide the ability for one to get value it returned from Entry()
669 You shouldn't hurry to create all the threads joinable, however, because this
670 has a disadvantage as well: you @b must Wait() for a joinable thread or the
671 system resources used by it will never be freed, and you also must delete the
672 corresponding wxThread object yourself if you did not create it on the stack.
673 In contrast, detached threads are of the "fire-and-forget" kind: you only have
674 to start a detached thread and it will terminate and destroy itself.
677 @section thread_deletion wxThread Deletion
679 Regardless of whether it has terminated or not, you should call Wait() on a
680 @b joinable thread to release its memory, as outlined in @ref thread_types.
681 If you created a joinable thread on the heap, remember to delete it manually
682 with the @c delete operator or similar means as only detached threads handle
683 this type of memory management.
685 Since @b detached threads delete themselves when they are finished processing,
686 you should take care when calling a routine on one. If you are certain the
687 thread is still running and would like to end it, you may call Delete()
688 to gracefully end it (which implies that the thread will be deleted after
689 that call to Delete()). It should be implied that you should @b never attempt
690 to delete a detached thread with the @c delete operator or similar means.
692 As mentioned, Wait() or Delete() functions attempt to gracefully terminate a
693 joinable and a detached thread, respectively. They do this by waiting until
694 the thread in question calls TestDestroy() or ends processing (i.e. returns
695 from wxThread::Entry).
697 Obviously, if the thread does call TestDestroy() and does not end, the
698 thread which called Wait() or Delete() will come to halt.
699 This is why it's important to call TestDestroy() in the Entry() routine of
700 your threads as often as possible and immediately exit when it returns @true.
702 As a last resort you can end the thread immediately through Kill(). It is
703 strongly recommended that you do not do this, however, as it does not free
704 the resources associated with the object (although the wxThread object of
705 detached threads will still be deleted) and could leave the C runtime
706 library in an undefined state.
709 @section thread_secondary wxWidgets Calls in Secondary Threads
711 All threads other than the "main application thread" (the one running
712 wxApp::OnInit() or the one your main function runs in, for example) are
713 considered "secondary threads". These include all threads created by Create()
714 or the corresponding constructors.
716 GUI calls, such as those to a wxWindow or wxBitmap are explicitly not safe
717 at all in secondary threads and could end your application prematurely.
718 This is due to several reasons, including the underlying native API and
719 the fact that wxThread does not run a GUI event loop similar to other APIs
722 A workaround for some wxWidgets ports is calling wxMutexGUIEnter()
723 before any GUI calls and then calling wxMutexGUILeave() afterwords. However,
724 the recommended way is to simply process the GUI calls in the main thread
725 through an event that is posted by wxQueueEvent().
726 This does not imply that calls to these classes are thread-safe, however,
727 as most wxWidgets classes are not thread-safe, including wxString.
730 @section thread_poll Don't Poll a wxThread
732 A common problem users experience with wxThread is that in their main thread
733 they will check the thread every now and then to see if it has ended through
734 IsRunning(), only to find that their application has run into problems
735 because the thread is using the default behavior (i.e. it's @b detached) and
736 has already deleted itself.
737 Naturally, they instead attempt to use joinable threads in place of the previous
738 behavior. However, polling a wxThread for when it has ended is in general a
739 bad idea - in fact calling a routine on any running wxThread should be avoided
740 if possible. Instead, find a way to notify yourself when the thread has ended.
742 Usually you only need to notify the main thread, in which case you can
743 post an event to it via wxQueueEvent().
744 In the case of secondary threads you can call a routine of another class
745 when the thread is about to complete processing and/or set the value of
746 a variable, possibly using mutexes (see wxMutex) and/or other synchronization
752 @see wxThreadHelper, wxMutex, wxCondition, wxCriticalSection,
759 The return type for the thread functions.
761 typedef void* ExitCode
;
764 This constructor creates a new detached (default) or joinable C++
765 thread object. It does not create or start execution of the real thread -
766 for this you should use the Create() and Run() methods.
768 The possible values for @a kind parameters are:
769 - @b wxTHREAD_DETACHED - Creates a detached thread.
770 - @b wxTHREAD_JOINABLE - Creates a joinable thread.
772 wxThread(wxThreadKind kind
= wxTHREAD_DETACHED
);
775 The destructor frees the resources associated with the thread.
776 Notice that you should never delete a detached thread -- you may only call
777 Delete() on it or wait until it terminates (and auto destructs) itself.
779 Because the detached threads delete themselves, they can only be allocated on the heap.
780 Joinable threads should be deleted explicitly. The Delete() and Kill() functions
781 will not delete the C++ thread object. It is also safe to allocate them on stack.
786 Creates a new thread.
788 The thread object is created in the suspended state, and you should call Run()
789 to start running it. You may optionally specify the stack size to be allocated
790 to it (Ignored on platforms that don't support setting it explicitly,
791 eg. Unix system without @c pthread_attr_setstacksize).
793 If you do not specify the stack size,the system's default value is used.
796 It is a good idea to explicitly specify a value as systems'
797 default values vary from just a couple of KB on some systems (BSD and
798 OS/2 systems) to one or several MB (Windows, Solaris, Linux).
799 So, if you have a thread that requires more than just a few KB of memory, you
800 will have mysterious problems on some platforms but not on the common ones.
801 On the other hand, just indicating a large stack size by default will give you
802 performance issues on those systems with small default stack since those
803 typically use fully committed memory for the stack.
804 On the contrary, if you use a lot of threads (say several hundred),
805 virtual adress space can get tight unless you explicitly specify a
806 smaller amount of thread stack space for each thread.
809 - @b wxTHREAD_NO_ERROR - No error.
810 - @b wxTHREAD_NO_RESOURCE - There were insufficient resources to create the thread.
811 - @b wxTHREAD_NO_RUNNING - The thread is already running
813 wxThreadError
Create(unsigned int stackSize
= 0);
816 Calling Delete() gracefully terminates a @b detached thread, either when
817 the thread calls TestDestroy() or when it finishes processing.
820 While this could work on a joinable thread you simply should not
821 call this routine on them as afterwards you may not be able to call
822 Wait() to free the memory of that thread.
824 See @ref thread_deletion for a broader explanation of this routine.
826 wxThreadError
Delete(void** rc
= NULL
);
829 Returns the number of system CPUs or -1 if the value is unknown.
831 @see SetConcurrency()
833 static int GetCPUCount();
836 Returns the platform specific thread ID of the current thread as a long.
837 This can be used to uniquely identify threads, even if they are not wxThreads.
839 static unsigned long GetCurrentId();
842 Gets the thread identifier: this is a platform dependent number that uniquely
843 identifies the thread throughout the system during its existence
844 (i.e. the thread identifiers may be reused).
846 wxThreadIdType
GetId() const;
849 Gets the priority of the thread, between zero and 100.
851 The following priorities are defined:
852 - @b WXTHREAD_MIN_PRIORITY: 0
853 - @b WXTHREAD_DEFAULT_PRIORITY: 50
854 - @b WXTHREAD_MAX_PRIORITY: 100
856 unsigned int GetPriority() const;
859 Returns @true if the thread is alive (i.e. started and not terminating).
861 Note that this function can only safely be used with joinable threads, not
862 detached ones as the latter delete themselves and so when the real thread is
863 no longer alive, it is not possible to call this function because
864 the wxThread object no longer exists.
866 bool IsAlive() const;
869 Returns @true if the thread is of the detached kind, @false if it is a
872 bool IsDetached() const;
875 Returns @true if the calling thread is the main application thread.
877 static bool IsMain();
880 Returns @true if the thread is paused.
882 bool IsPaused() const;
885 Returns @true if the thread is running.
887 This method may only be safely used for joinable threads, see the remark in
890 bool IsRunning() const;
893 Immediately terminates the target thread.
895 @b "This function is dangerous and should be used with extreme care"
896 (and not used at all whenever possible)! The resources allocated to the
897 thread will not be freed and the state of the C runtime library may become
898 inconsistent. Use Delete() for detached threads or Wait() for joinable
901 For detached threads Kill() will also delete the associated C++ object.
902 However this will not happen for joinable threads and this means that you will
903 still have to delete the wxThread object yourself to avoid memory leaks.
905 In neither case OnExit() of the dying thread will be called, so no
906 thread-specific cleanup will be performed.
907 This function can only be called from another thread context, i.e. a thread
910 It is also an error to call this function for a thread which is not running or
911 paused (in the latter case, the thread will be resumed first) -- if you do it,
912 a @b wxTHREAD_NOT_RUNNING error will be returned.
914 wxThreadError
Kill();
917 Called when the thread exits.
919 This function is called in the context of the thread associated with the
920 wxThread object, not in the context of the main thread.
921 This function will not be called if the thread was @ref Kill() killed.
923 This function should never be called directly.
925 virtual void OnExit();
930 Under some implementations (Win32), the thread is suspended immediately,
931 under others it will only be suspended when it calls TestDestroy() for
932 the next time (hence, if the thread doesn't call it at all, it won't be
935 This function can only be called from another thread context.
937 wxThreadError
Pause();
940 Resumes a thread suspended by the call to Pause().
942 This function can only be called from another thread context.
944 wxThreadError
Resume();
947 Starts the thread execution. Should be called after
950 This function can only be called from another thread context.
955 Sets the thread concurrency level for this process.
957 This is, roughly, the number of threads that the system tries to schedule
959 The value of 0 for @a level may be used to set the default one.
961 @return @true on success or @false otherwise (for example, if this function is
962 not implemented for this platform -- currently everything except Solaris).
964 static bool SetConcurrency(size_t level
);
967 Sets the priority of the thread, between 0 and 100.
968 It can only be set after calling Create() but before calling Run().
970 The following priorities are defined:
971 - @b WXTHREAD_MIN_PRIORITY: 0
972 - @b WXTHREAD_DEFAULT_PRIORITY: 50
973 - @b WXTHREAD_MAX_PRIORITY: 100
975 void SetPriority(unsigned int priority
);
978 Pauses the thread execution for the given amount of time.
980 This is the same as wxMilliSleep().
982 static void Sleep(unsigned long milliseconds
);
985 This function should be called periodically by the thread to ensure that
986 calls to Pause() and Delete() will work.
988 If it returns @true, the thread should exit as soon as possible.
989 Notice that under some platforms (POSIX), implementation of Pause() also
990 relies on this function being called, so not calling it would prevent
991 both stopping and suspending thread from working.
993 virtual bool TestDestroy();
996 Return the thread object for the calling thread.
998 @NULL is returned if the calling thread is the main (GUI) thread, but
999 IsMain() should be used to test whether the thread is really the main one
1000 because @NULL may also be returned for the thread not created with wxThread
1001 class. Generally speaking, the return value for such a thread is undefined.
1003 static wxThread
* This();
1006 Waits for a joinable thread to terminate and returns the value the thread
1007 returned from Entry() or @c "(ExitCode)-1" on error. Notice that, unlike
1008 Delete(), this function doesn't cancel the thread in any way so the caller
1009 waits for as long as it takes to the thread to exit.
1011 You can only Wait() for @b joinable (not detached) threads.
1012 This function can only be called from another thread context.
1014 See @ref thread_deletion for a broader explanation of this routine.
1019 Give the rest of the thread time slice to the system allowing the other
1022 Note that using this function is @b strongly discouraged, since in
1023 many cases it indicates a design weakness of your threading model
1024 (as does using Sleep() functions).
1026 Threads should use the CPU in an efficient manner, i.e. they should
1027 do their current work efficiently, then as soon as the work is done block
1028 on a wakeup event (wxCondition, wxMutex, select(), poll(), ...) which will
1029 get signalled e.g. by other threads or a user device once further thread
1031 Using Yield() or Sleep() indicates polling-type behaviour, since we're
1032 fuzzily giving up our timeslice and wait until sometime later we'll get
1033 reactivated, at which time we realize that there isn't really much to do
1034 and Yield() again...
1036 The most critical characteristic of Yield() is that it's operating system
1037 specific: there may be scheduler changes which cause your thread to not
1038 wake up relatively soon again, but instead many seconds later,
1039 causing huge performance issues for your application.
1042 With a well-behaving, CPU-efficient thread the operating system is likely
1043 to properly care for its reactivation the moment it needs it, whereas with
1044 non-deterministic, Yield-using threads all bets are off and the system
1045 scheduler is free to penalize drastically</strong>, and this effect gets worse
1046 with increasing system load due to less free CPU resources available.
1047 You may refer to various Linux kernel @c sched_yield discussions for more
1052 static void Yield();
1057 This is the entry point of the thread.
1059 This function is pure virtual and must be implemented by any derived class.
1060 The thread execution will start here.
1062 The returned value is the thread exit code which is only useful for
1063 joinable threads and is the value returned by Wait().
1064 This function is called by wxWidgets itself and should never be called
1067 virtual ExitCode
Entry() = 0;
1070 This is a protected function of the wxThread class and thus can only be called
1071 from a derived class. It also can only be called in the context of this
1072 thread, i.e. a thread can only exit from itself, not from another thread.
1074 This function will terminate the OS thread (i.e. stop the associated path of
1075 execution) and also delete the associated C++ object for detached threads.
1076 OnExit() will be called just before exiting.
1078 void Exit(ExitCode exitcode
= 0);
1082 /** See wxSemaphore. */
1085 wxSEMA_NO_ERROR
= 0,
1086 wxSEMA_INVALID
, //!< semaphore hasn't been initialized successfully
1087 wxSEMA_BUSY
, //!< returned by TryWait() if Wait() would block
1088 wxSEMA_TIMEOUT
, //!< returned by WaitTimeout()
1089 wxSEMA_OVERFLOW
, //!< Post() would increase counter past the max
1096 wxSemaphore is a counter limiting the number of threads concurrently accessing
1097 a shared resource. This counter is always between 0 and the maximum value
1098 specified during the semaphore creation. When the counter is strictly greater
1099 than 0, a call to wxSemaphore::Wait() returns immediately and decrements the
1100 counter. As soon as it reaches 0, any subsequent calls to wxSemaphore::Wait
1101 block and only return when the semaphore counter becomes strictly positive
1102 again as the result of calling wxSemaphore::Post which increments the counter.
1104 In general, semaphores are useful to restrict access to a shared resource
1105 which can only be accessed by some fixed number of clients at the same time.
1106 For example, when modeling a hotel reservation system a semaphore with the counter
1107 equal to the total number of available rooms could be created. Each time a room
1108 is reserved, the semaphore should be acquired by calling wxSemaphore::Wait
1109 and each time a room is freed it should be released by calling wxSemaphore::Post.
1112 @category{threading}
1118 Specifying a @a maxcount of 0 actually makes wxSemaphore behave as if
1119 there is no upper limit. If @a maxcount is 1, the semaphore behaves almost as a
1120 mutex (but unlike a mutex it can be released by a thread different from the one
1123 @a initialcount is the initial value of the semaphore which must be between
1124 0 and @a maxcount (if it is not set to 0).
1126 wxSemaphore(int initialcount
= 0, int maxcount
= 0);
1129 Destructor is not virtual, don't use this class polymorphically.
1134 Increments the semaphore count and signals one of the waiting
1135 threads in an atomic way. Returns @e wxSEMA_OVERFLOW if the count
1136 would increase the counter past the maximum.
1139 - wxSEMA_NO_ERROR: There was no error.
1140 - wxSEMA_INVALID : Semaphore hasn't been initialized successfully.
1141 - wxSEMA_OVERFLOW: Post() would increase counter past the max.
1142 - wxSEMA_MISC_ERROR: Miscellaneous error.
1147 Same as Wait(), but returns immediately.
1150 - wxSEMA_NO_ERROR: There was no error.
1151 - wxSEMA_INVALID: Semaphore hasn't been initialized successfully.
1152 - wxSEMA_BUSY: Returned by TryWait() if Wait() would block, i.e. the count is zero.
1153 - wxSEMA_MISC_ERROR: Miscellaneous error.
1155 wxSemaError
TryWait();
1158 Wait indefinitely until the semaphore count becomes strictly positive
1159 and then decrement it and return.
1162 - wxSEMA_NO_ERROR: There was no error.
1163 - wxSEMA_INVALID: Semaphore hasn't been initialized successfully.
1164 - wxSEMA_MISC_ERROR: Miscellaneous error.
1169 Same as Wait(), but with a timeout limit.
1172 - wxSEMA_NO_ERROR: There was no error.
1173 - wxSEMA_INVALID: Semaphore hasn't been initialized successfully.
1174 - wxSEMA_TIMEOUT: Timeout occurred without receiving semaphore.
1175 - wxSEMA_MISC_ERROR: Miscellaneous error.
1177 wxSemaError
WaitTimeout(unsigned long timeout_millis
);
1183 @class wxMutexLocker
1185 This is a small helper class to be used with wxMutex objects.
1187 A wxMutexLocker acquires a mutex lock in the constructor and releases
1188 (or unlocks) the mutex in the destructor making it much more difficult to
1189 forget to release a mutex (which, in general, will promptly lead to serious
1190 problems). See wxMutex for an example of wxMutexLocker usage.
1193 @category{threading}
1195 @see wxMutex, wxCriticalSectionLocker
1201 Constructs a wxMutexLocker object associated with mutex and locks it.
1202 Call IsOk() to check if the mutex was successfully locked.
1204 wxMutexLocker(wxMutex
& mutex
);
1207 Destructor releases the mutex if it was successfully acquired in the ctor.
1212 Returns @true if mutex was acquired in the constructor, @false otherwise.
1219 The possible wxMutex kinds.
1223 /** Normal non-recursive mutex: try to always use this one. */
1226 /** Recursive mutex: don't use these ones with wxCondition. */
1232 The possible wxMutex errors.
1236 /** The operation completed successfully. */
1237 wxMUTEX_NO_ERROR
= 0,
1239 /** The mutex hasn't been initialized. */
1242 /** The mutex is already locked by the calling thread. */
1245 /** The mutex is already locked by another thread. */
1248 /** An attempt to unlock a mutex which is not locked. */
1251 /** wxMutex::LockTimeout() has timed out. */
1254 /** Any other error */
1262 A mutex object is a synchronization object whose state is set to signaled when
1263 it is not owned by any thread, and nonsignaled when it is owned. Its name comes
1264 from its usefulness in coordinating mutually-exclusive access to a shared
1265 resource as only one thread at a time can own a mutex object.
1267 Mutexes may be recursive in the sense that a thread can lock a mutex which it
1268 had already locked before (instead of dead locking the entire process in this
1269 situation by starting to wait on a mutex which will never be released while the
1270 thread is waiting) but using them is not recommended under Unix and they are
1271 @b not recursive by default. The reason for this is that recursive
1272 mutexes are not supported by all Unix flavours and, worse, they cannot be used
1275 For example, when several threads use the data stored in the linked list,
1276 modifications to the list should only be allowed to one thread at a time
1277 because during a new node addition the list integrity is temporarily broken
1278 (this is also called @e program @e invariant).
1281 // this variable has an "s_" prefix because it is static: seeing an "s_" in
1282 // a multithreaded program is in general a good sign that you should use a
1283 // mutex (or a critical section)
1284 static wxMutex *s_mutexProtectingTheGlobalData;
1286 // we store some numbers in this global array which is presumably used by
1287 // several threads simultaneously
1290 void MyThread::AddNewNode(int num)
1292 // ensure that no other thread accesses the list
1293 s_mutexProtectingTheGlobalList->Lock();
1297 s_mutexProtectingTheGlobalList->Unlock();
1300 // return true if the given number is greater than all array elements
1301 bool MyThread::IsGreater(int num)
1303 // before using the list we must acquire the mutex
1304 wxMutexLocker lock(s_mutexProtectingTheGlobalData);
1306 size_t count = s_data.Count();
1307 for ( size_t n = 0; n < count; n++ )
1309 if ( s_data[n] > num )
1317 Notice how wxMutexLocker was used in the second function to ensure that the
1318 mutex is unlocked in any case: whether the function returns true or false
1319 (because the destructor of the local object @e lock is always called).
1320 Using this class instead of directly using wxMutex is, in general, safer
1321 and is even more so if your program uses C++ exceptions.
1324 @category{threading}
1326 @see wxThread, wxCondition, wxMutexLocker, wxCriticalSection
1332 Default constructor.
1334 wxMutex(wxMutexType type
= wxMUTEX_DEFAULT
);
1337 Destroys the wxMutex object.
1342 Locks the mutex object.
1343 This is equivalent to LockTimeout() with infinite timeout.
1345 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_DEAD_LOCK.
1347 wxMutexError
Lock();
1350 Try to lock the mutex object during the specified time interval.
1352 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_DEAD_LOCK, @c wxMUTEX_TIMEOUT.
1354 wxMutexError
LockTimeout(unsigned long msec
);
1357 Tries to lock the mutex object. If it can't, returns immediately with an error.
1359 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_BUSY.
1361 wxMutexError
TryLock();
1364 Unlocks the mutex object.
1366 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_UNLOCKED.
1368 wxMutexError
Unlock();
1373 // ============================================================================
1374 // Global functions/macros
1375 // ============================================================================
1377 /** @ingroup group_funcmacro_thread */
1381 This macro declares a (static) critical section object named @a cs if
1382 @c wxUSE_THREADS is 1 and does nothing if it is 0.
1384 @header{wx/thread.h}
1386 #define wxCRIT_SECT_DECLARE(cs)
1389 This macro declares a critical section object named @a cs if
1390 @c wxUSE_THREADS is 1 and does nothing if it is 0. As it doesn't include
1391 the @c static keyword (unlike wxCRIT_SECT_DECLARE()), it can be used to
1392 declare a class or struct member which explains its name.
1394 @header{wx/thread.h}
1396 #define wxCRIT_SECT_DECLARE_MEMBER(cs)
1399 This macro creates a wxCriticalSectionLocker named @a name and associated
1400 with the critical section @a cs if @c wxUSE_THREADS is 1 and does nothing
1403 @header{wx/thread.h}
1405 #define wxCRIT_SECT_LOCKER(name, cs)
1408 This macro combines wxCRIT_SECT_DECLARE() and wxCRIT_SECT_LOCKER(): it
1409 creates a static critical section object and also the lock object
1410 associated with it. Because of this, it can be only used inside a function,
1411 not at global scope. For example:
1416 static int s_counter = 0;
1418 wxCRITICAL_SECTION(counter);
1424 Note that this example assumes that the function is called the first time
1425 from the main thread so that the critical section object is initialized
1426 correctly by the time other threads start calling it, if this is not the
1427 case this approach can @b not be used and the critical section must be made
1430 @header{wx/thread.h}
1432 #define wxCRITICAL_SECTION(name)
1435 This macro is equivalent to
1436 @ref wxCriticalSection::Leave "critical_section.Leave()" if
1437 @c wxUSE_THREADS is 1 and does nothing if it is 0.
1439 @header{wx/thread.h}
1441 #define wxLEAVE_CRIT_SECT(critical_section)
1444 This macro is equivalent to
1445 @ref wxCriticalSection::Enter "critical_section.Enter()" if
1446 @c wxUSE_THREADS is 1 and does nothing if it is 0.
1448 @header{wx/thread.h}
1450 #define wxENTER_CRIT_SECT(critical_section)
1453 Returns @true if this thread is the main one. Always returns @true if
1454 @c wxUSE_THREADS is 0.
1456 @header{wx/thread.h}
1458 bool wxIsMainThread();
1461 This function must be called when any thread other than the main GUI thread
1462 wants to get access to the GUI library. This function will block the
1463 execution of the calling thread until the main thread (or any other thread
1464 holding the main GUI lock) leaves the GUI library and no other thread will
1465 enter the GUI library until the calling thread calls wxMutexGuiLeave().
1467 Typically, these functions are used like this:
1470 void MyThread::Foo(void)
1472 // before doing any GUI calls we must ensure that
1473 // this thread is the only one doing it!
1478 my_window-DrawSomething();
1484 This function is only defined on platforms which support preemptive
1487 @note Under GTK, no creation of top-level windows is allowed in any thread
1490 @header{wx/thread.h}
1492 void wxMutexGuiEnter();
1495 This function is only defined on platforms which support preemptive
1498 @see wxMutexGuiEnter()
1500 @header{wx/thread.h}
1502 void wxMutexGuiLeave();