]> git.saurik.com Git - wxWidgets.git/blame_incremental - interface/wx/thread.h
Make storing non-trivial data in wxThreadSpecificInfo possible.
[wxWidgets.git] / interface / wx / thread.h
... / ...
CommitLineData
1/////////////////////////////////////////////////////////////////////////////
2// Name: thread.h
3// Purpose: interface of all thread-related wxWidgets classes
4// Author: wxWidgets team
5// Licence: wxWindows licence
6/////////////////////////////////////////////////////////////////////////////
7
8
9/** See wxCondition. */
10enum wxCondError
11{
12 wxCOND_NO_ERROR = 0,
13 wxCOND_INVALID,
14 wxCOND_TIMEOUT, //!< WaitTimeout() has timed out
15 wxCOND_MISC_ERROR
16};
17
18
19/**
20 @class wxCondition
21
22 wxCondition variables correspond to pthread conditions or to Win32 event objects.
23 They may be used in a multithreaded application to wait until the given condition
24 becomes @true which happens when the condition becomes signaled.
25
26 For example, if a worker thread is doing some long task and another thread has
27 to wait until it is finished, the latter thread will wait on the condition
28 object and the worker thread will signal it on exit (this example is not
29 perfect because in this particular case it would be much better to just
30 wxThread::Wait for the worker thread, but if there are several worker threads
31 it already makes much more sense).
32
33 Note that a call to wxCondition::Signal may happen before the other thread calls
34 wxCondition::Wait and, just as with the pthread conditions, the signal is then
35 lost and so if you want to be sure that you don't miss it you must keep the
36 mutex associated with the condition initially locked and lock it again before calling
37 wxCondition::Signal. Of course, this means that this call is going to block
38 until wxCondition::Wait is called by another thread.
39
40 @section condition_example Example
41
42 This example shows how a main thread may launch a worker thread which starts
43 running and then waits until the main thread signals it to continue:
44
45 @code
46 class MySignallingThread : public wxThread
47 {
48 public:
49 MySignallingThread(wxMutex *mutex, wxCondition *condition)
50 {
51 m_mutex = mutex;
52 m_condition = condition;
53 }
54
55 virtual ExitCode Entry()
56 {
57 ... do our job ...
58
59 // tell the other(s) thread(s) that we're about to terminate: we must
60 // lock the mutex first or we might signal the condition before the
61 // waiting threads start waiting on it!
62 wxMutexLocker lock(*m_mutex);
63 m_condition->Broadcast(); // same as Signal() here -- one waiter only
64
65 return 0;
66 }
67
68 private:
69 wxCondition *m_condition;
70 wxMutex *m_mutex;
71 };
72
73 int main()
74 {
75 wxMutex mutex;
76 wxCondition condition(mutex);
77
78 // the mutex should be initially locked
79 mutex.Lock();
80
81 // create and run the thread but notice that it won't be able to
82 // exit (and signal its exit) before we unlock the mutex below
83 MySignallingThread *thread = new MySignallingThread(&mutex, &condition);
84
85 thread->Run();
86
87 // wait for the thread termination: Wait() atomically unlocks the mutex
88 // which allows the thread to continue and starts waiting
89 condition.Wait();
90
91 // now we can exit
92 return 0;
93 }
94 @endcode
95
96 Of course, here it would be much better to simply use a joinable thread and
97 call wxThread::Wait on it, but this example does illustrate the importance of
98 properly locking the mutex when using wxCondition.
99
100 @library{wxbase}
101 @category{threading}
102
103 @see wxThread, wxMutex
104*/
105class wxCondition
106{
107public:
108 /**
109 Default and only constructor.
110 The @a mutex must be locked by the caller before calling Wait() function.
111 Use IsOk() to check if the object was successfully initialized.
112 */
113 wxCondition(wxMutex& mutex);
114
115 /**
116 Destroys the wxCondition object.
117
118 The destructor is not virtual so this class should not be used polymorphically.
119 */
120 ~wxCondition();
121
122 /**
123 Broadcasts to all waiting threads, waking all of them up.
124
125 Note that this method may be called whether the mutex associated with
126 this condition is locked or not.
127
128 @see Signal()
129 */
130 wxCondError Broadcast();
131
132 /**
133 Returns @true if the object had been initialized successfully, @false
134 if an error occurred.
135 */
136 bool IsOk() const;
137
138 /**
139 Signals the object waking up at most one thread.
140
141 If several threads are waiting on the same condition, the exact thread
142 which is woken up is undefined. If no threads are waiting, the signal is
143 lost and the condition would have to be signalled again to wake up any
144 thread which may start waiting on it later.
145
146 Note that this method may be called whether the mutex associated with this
147 condition is locked or not.
148
149 @see Broadcast()
150 */
151 wxCondError Signal();
152
153 /**
154 Waits until the condition is signalled.
155
156 This method atomically releases the lock on the mutex associated with this
157 condition (this is why it must be locked prior to calling Wait()) and puts the
158 thread to sleep until Signal() or Broadcast() is called.
159 It then locks the mutex again and returns.
160
161 Note that even if Signal() had been called before Wait() without waking
162 up any thread, the thread would still wait for another one and so it is
163 important to ensure that the condition will be signalled after
164 Wait() or the thread may sleep forever.
165
166 @return Returns wxCOND_NO_ERROR on success, another value if an error occurred.
167
168 @see WaitTimeout()
169 */
170 wxCondError Wait();
171
172 /**
173 Waits until the condition is signalled and the associated condition true.
174
175 This is a convenience overload that may be used to ignore spurious
176 awakenings while waiting for a specific condition to become true.
177
178 Equivalent to
179 @code
180 while ( !predicate() )
181 {
182 wxCondError e = Wait();
183 if ( e != wxCOND_NO_ERROR )
184 return e;
185 }
186 return wxCOND_NO_ERROR;
187 @endcode
188
189 The predicate would typically be a C++11 lambda:
190 @code
191 condvar.Wait([]{return value == 1;});
192 @endcode
193
194 @since 3.0
195 */
196 template<typename Functor>
197 wxCondError Wait(const Functor& predicate);
198
199 /**
200 Waits until the condition is signalled or the timeout has elapsed.
201
202 This method is identical to Wait() except that it returns, with the
203 return code of @c wxCOND_TIMEOUT as soon as the given timeout expires.
204
205 @param milliseconds
206 Timeout in milliseconds
207
208 @return Returns wxCOND_NO_ERROR if the condition was signalled,
209 wxCOND_TIMEOUT if the timeout elapsed before this happened or
210 another error code from wxCondError enum.
211 */
212 wxCondError WaitTimeout(unsigned long milliseconds);
213};
214
215
216/**
217 @class wxCriticalSectionLocker
218
219 This is a small helper class to be used with wxCriticalSection objects.
220
221 A wxCriticalSectionLocker enters the critical section in the constructor and
222 leaves it in the destructor making it much more difficult to forget to leave
223 a critical section (which, in general, will lead to serious and difficult
224 to debug problems).
225
226 Example of using it:
227
228 @code
229 void Set Foo()
230 {
231 // gs_critSect is some (global) critical section guarding access to the
232 // object "foo"
233 wxCriticalSectionLocker locker(gs_critSect);
234
235 if ( ... )
236 {
237 // do something
238 ...
239
240 return;
241 }
242
243 // do something else
244 ...
245
246 return;
247 }
248 @endcode
249
250 Without wxCriticalSectionLocker, you would need to remember to manually leave
251 the critical section before each @c return.
252
253 @library{wxbase}
254 @category{threading}
255
256 @see wxCriticalSection, wxMutexLocker
257*/
258class wxCriticalSectionLocker
259{
260public:
261 /**
262 Constructs a wxCriticalSectionLocker object associated with given
263 @a criticalsection and enters it.
264 */
265 wxCriticalSectionLocker(wxCriticalSection& criticalsection);
266
267 /**
268 Destructor leaves the critical section.
269 */
270 ~wxCriticalSectionLocker();
271};
272
273
274
275/**
276 @class wxThreadHelper
277
278 The wxThreadHelper class is a mix-in class that manages a single background
279 thread, either detached or joinable (see wxThread for the differences).
280 By deriving from wxThreadHelper, a class can implement the thread
281 code in its own wxThreadHelper::Entry() method and easily share data and
282 synchronization objects between the main thread and the worker thread.
283
284 Doing this prevents the awkward passing of pointers that is needed when the
285 original object in the main thread needs to synchronize with its worker thread
286 in its own wxThread derived object.
287
288 For example, wxFrame may need to make some calculations in a background thread
289 and then display the results of those calculations in the main window.
290
291 Ordinarily, a wxThread derived object would be created with the calculation
292 code implemented in wxThread::Entry. To access the inputs to the calculation,
293 the frame object would often need to pass a pointer to itself to the thread object.
294 Similarly, the frame object would hold a pointer to the thread object.
295
296 Shared data and synchronization objects could be stored in either object
297 though the object without the data would have to access the data through
298 a pointer.
299 However with wxThreadHelper the frame object and the thread object are
300 treated as the same object. Shared data and synchronization variables are
301 stored in the single object, eliminating a layer of indirection and the
302 associated pointers.
303
304 Example:
305 @code
306 wxDECLARE_EVENT(myEVT_THREAD_UPDATE, wxThreadEvent);
307
308 class MyFrame : public wxFrame, public wxThreadHelper
309 {
310 public:
311 MyFrame(...) { ... }
312 ~MyFrame()
313 {
314 // it's better to do any thread cleanup in the OnClose()
315 // event handler, rather than in the destructor.
316 // This is because the event loop for a top-level window is not
317 // active anymore when its destructor is called and if the thread
318 // sends events when ending, they won't be processed unless
319 // you ended the thread from OnClose.
320 // See @ref overview_windowdeletion for more info.
321 }
322
323 ...
324 void DoStartALongTask();
325 void OnThreadUpdate(wxThreadEvent& evt);
326 void OnClose(wxCloseEvent& evt);
327 ...
328
329 protected:
330 virtual wxThread::ExitCode Entry();
331
332 // the output data of the Entry() routine:
333 char m_data[1024];
334 wxCriticalSection m_dataCS; // protects field above
335
336 wxDECLARE_EVENT_TABLE();
337 };
338
339 wxDEFINE_EVENT(myEVT_THREAD_UPDATE, wxThreadEvent)
340 wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
341 EVT_THREAD(wxID_ANY, myEVT_THREAD_UPDATE, MyFrame::OnThreadUpdate)
342 EVT_CLOSE(MyFrame::OnClose)
343 wxEND_EVENT_TABLE()
344
345 void MyFrame::DoStartALongTask()
346 {
347 // we want to start a long task, but we don't want our GUI to block
348 // while it's executed, so we use a thread to do it.
349 if (CreateThread(wxTHREAD_JOINABLE) != wxTHREAD_NO_ERROR)
350 {
351 wxLogError("Could not create the worker thread!");
352 return;
353 }
354
355 // go!
356 if (GetThread()->Run() != wxTHREAD_NO_ERROR)
357 {
358 wxLogError("Could not run the worker thread!");
359 return;
360 }
361 }
362
363 wxThread::ExitCode MyFrame::Entry()
364 {
365 // IMPORTANT:
366 // this function gets executed in the secondary thread context!
367
368 int offset = 0;
369
370 // here we do our long task, periodically calling TestDestroy():
371 while (!GetThread()->TestDestroy())
372 {
373 // since this Entry() is implemented in MyFrame context we don't
374 // need any pointer to access the m_data, m_processedData, m_dataCS
375 // variables... very nice!
376
377 // this is an example of the generic structure of a download thread:
378 char buffer[1024];
379 download_chunk(buffer, 1024); // this takes time...
380
381 {
382 // ensure no one reads m_data while we write it
383 wxCriticalSectionLocker lock(m_dataCS);
384 memcpy(m_data+offset, buffer, 1024);
385 offset += 1024;
386 }
387
388
389 // VERY IMPORTANT: do not call any GUI function inside this
390 // function; rather use wxQueueEvent():
391 wxQueueEvent(this, new wxThreadEvent(wxEVT_COMMAND_MYTHREAD_UPDATE));
392 // we used pointer 'this' assuming it's safe; see OnClose()
393 }
394
395 // TestDestroy() returned true (which means the main thread asked us
396 // to terminate as soon as possible) or we ended the long task...
397 return (wxThread::ExitCode)0;
398 }
399
400 void MyFrame::OnClose(wxCloseEvent&)
401 {
402 // important: before terminating, we _must_ wait for our joinable
403 // thread to end, if it's running; in fact it uses variables of this
404 // instance and posts events to *this event handler
405
406 if (GetThread() && // DoStartALongTask() may have not been called
407 GetThread()->IsRunning())
408 GetThread()->Wait();
409
410 Destroy();
411 }
412
413 void MyFrame::OnThreadUpdate(wxThreadEvent& evt)
414 {
415 // ...do something... e.g. m_pGauge->Pulse();
416
417 // read some parts of m_data just for fun:
418 wxCriticalSectionLocker lock(m_dataCS);
419 wxPrintf("%c", m_data[100]);
420 }
421 @endcode
422
423 @library{wxbase}
424 @category{threading}
425
426 @see wxThread, wxThreadEvent
427*/
428class wxThreadHelper
429{
430public:
431 /**
432 This constructor simply initializes internal member variables and tells
433 wxThreadHelper which type the thread internally managed should be.
434 */
435 wxThreadHelper(wxThreadKind kind = wxTHREAD_JOINABLE);
436
437 /**
438 The destructor frees the resources associated with the thread, forcing
439 it to terminate (it uses wxThread::Kill function).
440
441 Because of the wxThread::Kill unsafety, you should always wait
442 (with wxThread::Wait) for joinable threads to end or call wxThread::Delete
443 on detached threads, instead of relying on this destructor for stopping
444 the thread.
445 */
446 virtual ~wxThreadHelper();
447
448 /**
449 This is the entry point of the thread.
450
451 This function is pure virtual and must be implemented by any derived class.
452 The thread execution will start here.
453
454 You'll typically want your Entry() to look like:
455 @code
456 wxThread::ExitCode Entry()
457 {
458 while (!GetThread()->TestDestroy())
459 {
460 // ... do some work ...
461
462 if (IsWorkCompleted)
463 break;
464
465 if (HappenedStoppingError)
466 return (wxThread::ExitCode)1; // failure
467 }
468
469 return (wxThread::ExitCode)0; // success
470 }
471 @endcode
472
473 The returned value is the thread exit code which is only useful for
474 joinable threads and is the value returned by @c "GetThread()->Wait()".
475
476 This function is called by wxWidgets itself and should never be called
477 directly.
478 */
479 virtual ExitCode Entry() = 0;
480
481 /**
482 Callback called by Delete() before actually deleting the thread.
483
484 This function can be overridden by the derived class to perform some
485 specific task when the thread is gracefully destroyed. Notice that it
486 will be executed in the context of the thread that called Delete() and
487 <b>not</b> in this thread's context.
488
489 TestDestroy() will be true for the thread before OnDelete() gets
490 executed.
491
492 @since 2.9.2
493
494 @see OnKill()
495 */
496 virtual void OnDelete();
497
498 /**
499 Callback called by Kill() before actually killing the thread.
500
501 This function can be overridden by the derived class to perform some
502 specific task when the thread is terminated. Notice that it will be
503 executed in the context of the thread that called Kill() and <b>not</b>
504 in this thread's context.
505
506 @since 2.9.2
507
508 @see OnDelete()
509 */
510 virtual void OnKill();
511
512 /**
513 @deprecated
514 Use CreateThread() instead.
515 */
516 wxThreadError Create(unsigned int stackSize = 0);
517
518 /**
519 Creates a new thread of the given @a kind.
520
521 The thread object is created in the suspended state, and you
522 should call @ref wxThread::Run "GetThread()->Run()" to start running it.
523
524 You may optionally specify the stack size to be allocated to it (ignored
525 on platforms that don't support setting it explicitly, e.g. Unix).
526
527 @return One of the ::wxThreadError enum values.
528 */
529 wxThreadError CreateThread(wxThreadKind kind = wxTHREAD_JOINABLE,
530 unsigned int stackSize = 0);
531
532 /**
533 This is a public function that returns the wxThread object associated with
534 the thread.
535 */
536 wxThread* GetThread() const;
537
538 /**
539 Returns the last type of thread given to the CreateThread() function
540 or to the constructor.
541 */
542 wxThreadKind GetThreadKind() const;
543};
544
545/**
546 Possible critical section types
547*/
548
549enum wxCriticalSectionType
550{
551 wxCRITSEC_DEFAULT,
552 /** Recursive critical section under both Windows and Unix */
553
554 wxCRITSEC_NON_RECURSIVE
555 /** Non-recursive critical section under Unix, recursive under Windows */
556};
557
558/**
559 @class wxCriticalSection
560
561 A critical section object is used for exactly the same purpose as a wxMutex.
562 The only difference is that under Windows platform critical sections are only
563 visible inside one process, while mutexes may be shared among processes,
564 so using critical sections is slightly more efficient.
565
566 The terminology is also slightly different: mutex may be locked (or acquired)
567 and unlocked (or released) while critical section is entered and left by the program.
568
569 Finally, you should try to use wxCriticalSectionLocker class whenever
570 possible instead of directly using wxCriticalSection for the same reasons
571 wxMutexLocker is preferable to wxMutex - please see wxMutex for an example.
572
573 @library{wxbase}
574 @category{threading}
575
576 @note Critical sections can be used before the wxWidgets library is fully
577 initialized. In particular, it's safe to create global
578 wxCriticalSection instances.
579
580 @see wxThread, wxCondition, wxCriticalSectionLocker
581*/
582class wxCriticalSection
583{
584public:
585 /**
586 Default constructor initializes critical section object.
587 By default critical sections are recursive under Unix and Windows.
588 */
589 wxCriticalSection( wxCriticalSectionType critSecType = wxCRITSEC_DEFAULT );
590
591 /**
592 Destructor frees the resources.
593 */
594 ~wxCriticalSection();
595
596 /**
597 Enter the critical section (same as locking a mutex): if another thread
598 has already entered it, this call will block until the other thread
599 calls Leave().
600 There is no error return for this function.
601
602 After entering the critical section protecting a data variable,
603 the thread running inside the critical section may safely use/modify it.
604
605 Note that entering the same critical section twice or more from the same
606 thread doesn't result in a deadlock; in this case in fact this function will
607 immediately return.
608 */
609 void Enter();
610
611 /**
612 Try to enter the critical section (same as trying to lock a mutex).
613 If it can't, immediately returns false.
614
615 @since 2.9.3
616 */
617 bool TryEnter();
618
619 /**
620 Leave the critical section allowing other threads use the global data
621 protected by it. There is no error return for this function.
622 */
623 void Leave();
624};
625
626/**
627 The possible thread wait types.
628
629 @since 2.9.2
630*/
631enum wxThreadWait
632{
633 /**
634 No events are processed while waiting.
635
636 This is the default under all platforms except for wxMSW.
637 */
638 wxTHREAD_WAIT_BLOCK,
639
640 /**
641 Yield for event dispatching while waiting.
642
643 This flag is dangerous as it exposes the program using it to unexpected
644 reentrancies in the same way as calling wxYield() function does so you
645 are strongly advised to avoid its use and not wait for the thread
646 termination from the main (GUI) thread at all to avoid making your
647 application unresponsive.
648
649 Also notice that this flag is not portable as it is only implemented in
650 wxMSW and simply ignored under the other platforms.
651 */
652 wxTHREAD_WAIT_YIELD,
653
654 /**
655 Default wait mode for wxThread::Wait() and wxThread::Delete().
656
657 For compatibility reasons, the default wait mode is currently
658 wxTHREAD_WAIT_YIELD if WXWIN_COMPATIBILITY_2_8 is defined (and it is
659 by default). However, as mentioned above, you're strongly encouraged to
660 not use wxTHREAD_WAIT_YIELD and pass wxTHREAD_WAIT_BLOCK to wxThread
661 method explicitly.
662 */
663 wxTHREAD_WAIT_DEFAULT = wxTHREAD_WAIT_YIELD
664};
665
666/**
667 The possible thread kinds.
668*/
669enum wxThreadKind
670{
671 /** Detached thread */
672 wxTHREAD_DETACHED,
673
674 /** Joinable thread */
675 wxTHREAD_JOINABLE
676};
677
678/**
679 The possible thread errors.
680*/
681enum wxThreadError
682{
683 /** No error */
684 wxTHREAD_NO_ERROR = 0,
685
686 /** No resource left to create a new thread. */
687 wxTHREAD_NO_RESOURCE,
688
689 /** The thread is already running. */
690 wxTHREAD_RUNNING,
691
692 /** The thread isn't running. */
693 wxTHREAD_NOT_RUNNING,
694
695 /** Thread we waited for had to be killed. */
696 wxTHREAD_KILLED,
697
698 /** Some other error */
699 wxTHREAD_MISC_ERROR
700};
701
702/**
703 @class wxThread
704
705 A thread is basically a path of execution through a program.
706 Threads are sometimes called @e light-weight processes, but the fundamental difference
707 between threads and processes is that memory spaces of different processes are
708 separated while all threads share the same address space.
709
710 While it makes it much easier to share common data between several threads, it
711 also makes it much easier to shoot oneself in the foot, so careful use of
712 synchronization objects such as mutexes (see wxMutex) or critical sections
713 (see wxCriticalSection) is recommended.
714 In addition, don't create global thread objects because they allocate memory
715 in their constructor, which will cause problems for the memory checking system.
716
717
718 @section thread_types Types of wxThreads
719
720 There are two types of threads in wxWidgets: @e detached and @e joinable,
721 modeled after the POSIX thread API. This is different from the Win32 API
722 where all threads are joinable.
723
724 By default wxThreads in wxWidgets use the @b detached behaviour.
725 Detached threads delete themselves once they have completed, either by themselves
726 when they complete processing or through a call to Delete(), and thus
727 @b must be created on the heap (through the new operator, for example).
728
729 Typically you'll want to store the instances of the detached wxThreads you
730 allocate, so that you can call functions on them.
731 Because of their nature however you'll need to always use a critical section
732 when accessing them:
733
734 @code
735 // declare a new type of event, to be used by our MyThread class:
736 wxDECLARE_EVENT(wxEVT_COMMAND_MYTHREAD_COMPLETED, wxThreadEvent);
737 wxDECLARE_EVENT(wxEVT_COMMAND_MYTHREAD_UPDATE, wxThreadEvent);
738 class MyFrame;
739
740 class MyThread : public wxThread
741 {
742 public:
743 MyThread(MyFrame *handler)
744 : wxThread(wxTHREAD_DETACHED)
745 { m_pHandler = handler }
746 ~MyThread();
747
748 protected:
749 virtual ExitCode Entry();
750 MyFrame *m_pHandler;
751 };
752
753 class MyFrame : public wxFrame
754 {
755 public:
756 ...
757 ~MyFrame()
758 {
759 // it's better to do any thread cleanup in the OnClose()
760 // event handler, rather than in the destructor.
761 // This is because the event loop for a top-level window is not
762 // active anymore when its destructor is called and if the thread
763 // sends events when ending, they won't be processed unless
764 // you ended the thread from OnClose.
765 // See @ref overview_windowdeletion for more info.
766 }
767 ...
768 void DoStartThread();
769 void DoPauseThread();
770
771 // a resume routine would be nearly identic to DoPauseThread()
772 void DoResumeThread() { ... }
773
774 void OnThreadUpdate(wxThreadEvent&);
775 void OnThreadCompletion(wxThreadEvent&);
776 void OnClose(wxCloseEvent&);
777
778 protected:
779 MyThread *m_pThread;
780 wxCriticalSection m_pThreadCS; // protects the m_pThread pointer
781
782 wxDECLARE_EVENT_TABLE();
783 };
784
785 wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
786 EVT_CLOSE(MyFrame::OnClose)
787 EVT_MENU(Minimal_Start, MyFrame::DoStartThread)
788 EVT_COMMAND(wxID_ANY, wxEVT_COMMAND_MYTHREAD_UPDATE, MyFrame::OnThreadUpdate)
789 EVT_COMMAND(wxID_ANY, wxEVT_COMMAND_MYTHREAD_COMPLETED, MyFrame::OnThreadCompletion)
790 wxEND_EVENT_TABLE()
791
792 wxDEFINE_EVENT(wxEVT_COMMAND_MYTHREAD_COMPLETED, wxThreadEvent)
793 wxDEFINE_EVENT(wxEVT_COMMAND_MYTHREAD_UPDATE, wxThreadEvent)
794
795 void MyFrame::DoStartThread()
796 {
797 m_pThread = new MyThread(this);
798
799 if ( m_pThread->Run() != wxTHREAD_NO_ERROR )
800 {
801 wxLogError("Can't create the thread!");
802 delete m_pThread;
803 m_pThread = NULL;
804 }
805
806 // after the call to wxThread::Run(), the m_pThread pointer is "unsafe":
807 // at any moment the thread may cease to exist (because it completes its work).
808 // To avoid dangling pointers OnThreadExit() will set m_pThread
809 // to NULL when the thread dies.
810 }
811
812 wxThread::ExitCode MyThread::Entry()
813 {
814 while (!TestDestroy())
815 {
816 // ... do a bit of work...
817
818 wxQueueEvent(m_pHandler, new wxThreadEvent(wxEVT_COMMAND_MYTHREAD_UPDATE));
819 }
820
821 // signal the event handler that this thread is going to be destroyed
822 // NOTE: here we assume that using the m_pHandler pointer is safe,
823 // (in this case this is assured by the MyFrame destructor)
824 wxQueueEvent(m_pHandler, new wxThreadEvent(wxEVT_COMMAND_MYTHREAD_COMPLETED));
825
826 return (wxThread::ExitCode)0; // success
827 }
828
829 MyThread::~MyThread()
830 {
831 wxCriticalSectionLocker enter(m_pHandler->m_pThreadCS);
832
833 // the thread is being destroyed; make sure not to leave dangling pointers around
834 m_pHandler->m_pThread = NULL;
835 }
836
837 void MyFrame::OnThreadCompletion(wxThreadEvent&)
838 {
839 wxMessageOutputDebug().Printf("MYFRAME: MyThread exited!\n");
840 }
841
842 void MyFrame::OnThreadUpdate(wxThreadEvent&)
843 {
844 wxMessageOutputDebug().Printf("MYFRAME: MyThread update...\n");
845 }
846
847 void MyFrame::DoPauseThread()
848 {
849 // anytime we access the m_pThread pointer we must ensure that it won't
850 // be modified in the meanwhile; since only a single thread may be
851 // inside a given critical section at a given time, the following code
852 // is safe:
853 wxCriticalSectionLocker enter(m_pThreadCS);
854
855 if (m_pThread) // does the thread still exist?
856 {
857 // without a critical section, once reached this point it may happen
858 // that the OS scheduler gives control to the MyThread::Entry() function,
859 // which in turn may return (because it completes its work) making
860 // invalid the m_pThread pointer
861
862 if (m_pThread->Pause() != wxTHREAD_NO_ERROR )
863 wxLogError("Can't pause the thread!");
864 }
865 }
866
867 void MyFrame::OnClose(wxCloseEvent&)
868 {
869 {
870 wxCriticalSectionLocker enter(m_pThreadCS);
871
872 if (m_pThread) // does the thread still exist?
873 {
874 wxMessageOutputDebug().Printf("MYFRAME: deleting thread");
875
876 if (m_pThread->Delete() != wxTHREAD_NO_ERROR )
877 wxLogError("Can't delete the thread!");
878 }
879 } // exit from the critical section to give the thread
880 // the possibility to enter its destructor
881 // (which is guarded with m_pThreadCS critical section!)
882
883 while (1)
884 {
885 { // was the ~MyThread() function executed?
886 wxCriticalSectionLocker enter(m_pThreadCS);
887 if (!m_pThread) break;
888 }
889
890 // wait for thread completion
891 wxThread::This()->Sleep(1);
892 }
893
894 Destroy();
895 }
896 @endcode
897
898 For a more detailed and comprehensive example, see @sample{thread}.
899 For a simpler way to share data and synchronization objects between
900 the main and the secondary thread see wxThreadHelper.
901
902 Conversely, @b joinable threads do not delete themselves when they are done
903 processing and as such are safe to create on the stack. Joinable threads
904 also provide the ability for one to get value it returned from Entry()
905 through Wait().
906 You shouldn't hurry to create all the threads joinable, however, because this
907 has a disadvantage as well: you @b must Wait() for a joinable thread or the
908 system resources used by it will never be freed, and you also must delete the
909 corresponding wxThread object yourself if you did not create it on the stack.
910 In contrast, detached threads are of the "fire-and-forget" kind: you only have
911 to start a detached thread and it will terminate and destroy itself.
912
913
914 @section thread_deletion wxThread Deletion
915
916 Regardless of whether it has terminated or not, you should call Wait() on a
917 @b joinable thread to release its memory, as outlined in @ref thread_types.
918 If you created a joinable thread on the heap, remember to delete it manually
919 with the @c delete operator or similar means as only detached threads handle
920 this type of memory management.
921
922 Since @b detached threads delete themselves when they are finished processing,
923 you should take care when calling a routine on one. If you are certain the
924 thread is still running and would like to end it, you may call Delete()
925 to gracefully end it (which implies that the thread will be deleted after
926 that call to Delete()). It should be implied that you should @b never attempt
927 to delete a detached thread with the @c delete operator or similar means.
928
929 As mentioned, Wait() or Delete() functions attempt to gracefully terminate a
930 joinable and a detached thread, respectively. They do this by waiting until
931 the thread in question calls TestDestroy() or ends processing (i.e. returns
932 from wxThread::Entry).
933
934 Obviously, if the thread does call TestDestroy() and does not end, the
935 thread which called Wait() or Delete() will come to halt.
936 This is why it's important to call TestDestroy() in the Entry() routine of
937 your threads as often as possible and immediately exit when it returns @true.
938
939 As a last resort you can end the thread immediately through Kill(). It is
940 strongly recommended that you do not do this, however, as it does not free
941 the resources associated with the object (although the wxThread object of
942 detached threads will still be deleted) and could leave the C runtime
943 library in an undefined state.
944
945
946 @section thread_secondary wxWidgets Calls in Secondary Threads
947
948 All threads other than the "main application thread" (the one running
949 wxApp::OnInit() or the one your main function runs in, for example) are
950 considered "secondary threads".
951
952 GUI calls, such as those to a wxWindow or wxBitmap are explicitly not safe
953 at all in secondary threads and could end your application prematurely.
954 This is due to several reasons, including the underlying native API and
955 the fact that wxThread does not run a GUI event loop similar to other APIs
956 as MFC.
957
958 A workaround for some wxWidgets ports is calling wxMutexGUIEnter()
959 before any GUI calls and then calling wxMutexGUILeave() afterwords.
960 However, the recommended way is to simply process the GUI calls in the main
961 thread through an event that is posted by wxQueueEvent().
962 This does not imply that calls to these classes are thread-safe, however,
963 as most wxWidgets classes are not thread-safe, including wxString.
964
965
966 @section thread_poll Don't Poll a wxThread
967
968 A common problem users experience with wxThread is that in their main thread
969 they will check the thread every now and then to see if it has ended through
970 IsRunning(), only to find that their application has run into problems
971 because the thread is using the default behaviour (i.e. it's @b detached) and
972 has already deleted itself.
973 Naturally, they instead attempt to use joinable threads in place of the previous
974 behaviour. However, polling a wxThread for when it has ended is in general a
975 bad idea - in fact calling a routine on any running wxThread should be avoided
976 if possible. Instead, find a way to notify yourself when the thread has ended.
977
978 Usually you only need to notify the main thread, in which case you can
979 post an event to it via wxQueueEvent().
980 In the case of secondary threads you can call a routine of another class
981 when the thread is about to complete processing and/or set the value of
982 a variable, possibly using mutexes (see wxMutex) and/or other synchronization
983 means if necessary.
984
985 @library{wxbase}
986 @category{threading}
987
988 @see wxThreadHelper, wxMutex, wxCondition, wxCriticalSection,
989 @ref overview_thread
990*/
991class wxThread
992{
993public:
994 /**
995 The return type for the thread functions.
996 */
997 typedef void* ExitCode;
998
999 /**
1000 This constructor creates a new detached (default) or joinable C++
1001 thread object. It does not create or start execution of the real thread -
1002 for this you should use the Run() method.
1003
1004 The possible values for @a kind parameters are:
1005 - @b wxTHREAD_DETACHED - Creates a detached thread.
1006 - @b wxTHREAD_JOINABLE - Creates a joinable thread.
1007 */
1008 wxThread(wxThreadKind kind = wxTHREAD_DETACHED);
1009
1010 /**
1011 The destructor frees the resources associated with the thread.
1012 Notice that you should never delete a detached thread -- you may only call
1013 Delete() on it or wait until it terminates (and auto destructs) itself.
1014
1015 Because the detached threads delete themselves, they can only be allocated on the heap.
1016 Joinable threads should be deleted explicitly. The Delete() and Kill() functions
1017 will not delete the C++ thread object. It is also safe to allocate them on stack.
1018 */
1019 virtual ~wxThread();
1020
1021 /**
1022 Creates a new thread.
1023
1024 The thread object is created in the suspended state, and you should call Run()
1025 to start running it. You may optionally specify the stack size to be allocated
1026 to it (Ignored on platforms that don't support setting it explicitly,
1027 eg. Unix system without @c pthread_attr_setstacksize).
1028
1029 If you do not specify the stack size, the system's default value is used.
1030
1031 @note
1032 It is not necessary to call this method since 2.9.5, Run() will create
1033 the thread internally. You only need to call Create() if you need to do
1034 something with the thread (e.g. pass its ID to an external library)
1035 before it starts.
1036
1037 @warning
1038 It is a good idea to explicitly specify a value as systems'
1039 default values vary from just a couple of KB on some systems (BSD and
1040 OS/2 systems) to one or several MB (Windows, Solaris, Linux).
1041 So, if you have a thread that requires more than just a few KB of memory, you
1042 will have mysterious problems on some platforms but not on the common ones.
1043 On the other hand, just indicating a large stack size by default will give you
1044 performance issues on those systems with small default stack since those
1045 typically use fully committed memory for the stack.
1046 On the contrary, if you use a lot of threads (say several hundred),
1047 virtual address space can get tight unless you explicitly specify a
1048 smaller amount of thread stack space for each thread.
1049
1050 @return One of:
1051 - @b wxTHREAD_NO_ERROR - No error.
1052 - @b wxTHREAD_NO_RESOURCE - There were insufficient resources to create the thread.
1053 - @b wxTHREAD_NO_RUNNING - The thread is already running
1054 */
1055 wxThreadError Create(unsigned int stackSize = 0);
1056
1057 /**
1058 Calling Delete() gracefully terminates a @b detached thread, either when
1059 the thread calls TestDestroy() or when it finishes processing.
1060
1061 @param rc
1062 The thread exit code, if rc is not NULL.
1063
1064 @param waitMode
1065 As described in wxThreadWait documentation, wxTHREAD_WAIT_BLOCK
1066 should be used as the wait mode even although currently
1067 wxTHREAD_WAIT_YIELD is for compatibility reasons. This parameter is
1068 new in wxWidgets 2.9.2.
1069
1070 @note
1071 This function works on a joinable thread but in that case makes
1072 the TestDestroy() function of the thread return @true and then
1073 waits for its completion (i.e. it differs from Wait() because
1074 it asks the thread to terminate before waiting).
1075
1076 See @ref thread_deletion for a broader explanation of this routine.
1077 */
1078 wxThreadError Delete(ExitCode *rc = NULL,
1079 wxThreadWait waitMode = wxTHREAD_WAIT_BLOCK);
1080
1081 /**
1082 Returns the number of system CPUs or -1 if the value is unknown.
1083
1084 For multi-core systems the returned value is typically the total number
1085 of @e cores, since the OS usually abstract a single N-core CPU
1086 as N different cores.
1087
1088 @see SetConcurrency()
1089 */
1090 static int GetCPUCount();
1091
1092 /**
1093 Returns the platform specific thread ID of the current thread as a long.
1094
1095 This can be used to uniquely identify threads, even if they are not wxThreads.
1096
1097 @see GetMainId()
1098 */
1099 static wxThreadIdType GetCurrentId();
1100
1101 /**
1102 Gets the thread identifier: this is a platform dependent number that uniquely
1103 identifies the thread throughout the system during its existence
1104 (i.e.\ the thread identifiers may be reused).
1105 */
1106 wxThreadIdType GetId() const;
1107
1108 /**
1109 Returns the thread kind as it was given in the ctor.
1110
1111 @since 2.9.0
1112 */
1113 wxThreadKind GetKind() const;
1114
1115 /**
1116 Returns the thread ID of the main thread.
1117
1118 @see IsMain()
1119
1120 @since 2.9.1
1121 */
1122 static wxThreadIdType GetMainId();
1123
1124 /**
1125 Gets the priority of the thread, between 0 (lowest) and 100 (highest).
1126
1127 @see SetPriority()
1128 */
1129 unsigned int GetPriority() const;
1130
1131 /**
1132 Returns @true if the thread is alive (i.e.\ started and not terminating).
1133
1134 Note that this function can only safely be used with joinable threads, not
1135 detached ones as the latter delete themselves and so when the real thread is
1136 no longer alive, it is not possible to call this function because
1137 the wxThread object no longer exists.
1138 */
1139 bool IsAlive() const;
1140
1141 /**
1142 Returns @true if the thread is of the detached kind, @false if it is a
1143 joinable one.
1144 */
1145 bool IsDetached() const;
1146
1147 /**
1148 Returns @true if the calling thread is the main application thread.
1149
1150 Main thread in the context of wxWidgets is the one which initialized
1151 the library.
1152
1153 @see GetMainId(), GetCurrentId()
1154 */
1155 static bool IsMain();
1156
1157 /**
1158 Returns @true if the thread is paused.
1159 */
1160 bool IsPaused() const;
1161
1162 /**
1163 Returns @true if the thread is running.
1164
1165 This method may only be safely used for joinable threads, see the remark in
1166 IsAlive().
1167 */
1168 bool IsRunning() const;
1169
1170 /**
1171 Immediately terminates the target thread.
1172
1173 @b "This function is dangerous and should be used with extreme care"
1174 (and not used at all whenever possible)! The resources allocated to the
1175 thread will not be freed and the state of the C runtime library may become
1176 inconsistent. Use Delete() for detached threads or Wait() for joinable
1177 threads instead.
1178
1179 For detached threads Kill() will also delete the associated C++ object.
1180 However this will not happen for joinable threads and this means that you will
1181 still have to delete the wxThread object yourself to avoid memory leaks.
1182
1183 In neither case OnExit() of the dying thread will be called, so no
1184 thread-specific cleanup will be performed.
1185 This function can only be called from another thread context, i.e. a thread
1186 cannot kill itself.
1187
1188 It is also an error to call this function for a thread which is not running or
1189 paused (in the latter case, the thread will be resumed first) -- if you do it,
1190 a @b wxTHREAD_NOT_RUNNING error will be returned.
1191 */
1192 wxThreadError Kill();
1193
1194 /**
1195 Suspends the thread.
1196
1197 Under some implementations (Win32), the thread is suspended immediately,
1198 under others it will only be suspended when it calls TestDestroy() for
1199 the next time (hence, if the thread doesn't call it at all, it won't be
1200 suspended).
1201
1202 This function can only be called from another thread context.
1203 */
1204 wxThreadError Pause();
1205
1206 /**
1207 Resumes a thread suspended by the call to Pause().
1208
1209 This function can only be called from another thread context.
1210 */
1211 wxThreadError Resume();
1212
1213 /**
1214 Starts the thread execution.
1215
1216 Note that once you Run() a @b detached thread, @e any function call you do
1217 on the thread pointer (you must allocate it on the heap) is @e "unsafe";
1218 i.e. the thread may have terminated at any moment after Run() and your pointer
1219 may be dangling. See @ref thread_types for an example of safe manipulation
1220 of detached threads.
1221
1222 This function can only be called from another thread context.
1223
1224 Finally, note that once a thread has completed and its Entry() function
1225 returns, you cannot call Run() on it again (an assert will fail in debug
1226 builds or @c wxTHREAD_RUNNING will be returned in release builds).
1227 */
1228 wxThreadError Run();
1229
1230 /**
1231 Sets the thread concurrency level for this process.
1232
1233 This is, roughly, the number of threads that the system tries to schedule
1234 to run in parallel.
1235 The value of 0 for @a level may be used to set the default one.
1236
1237 @return @true on success or @false otherwise (for example, if this function is
1238 not implemented for this platform -- currently everything except Solaris).
1239 */
1240 static bool SetConcurrency(size_t level);
1241
1242 /**
1243 Sets the priority of the thread, between 0 (lowest) and 100 (highest).
1244
1245 The following symbolic constants can be used in addition to raw
1246 values in 0..100 range:
1247 - @c wxPRIORITY_MIN: 0
1248 - @c wxPRIORITY_DEFAULT: 50
1249 - @c wxPRIORITY_MAX: 100
1250 */
1251 void SetPriority(unsigned int priority);
1252
1253 /**
1254 Pauses the thread execution for the given amount of time.
1255
1256 This is the same as wxMilliSleep().
1257 */
1258 static void Sleep(unsigned long milliseconds);
1259
1260 /**
1261 This function should be called periodically by the thread to ensure that
1262 calls to Pause() and Delete() will work.
1263
1264 If it returns @true, the thread should exit as soon as possible.
1265 Notice that under some platforms (POSIX), implementation of Pause() also
1266 relies on this function being called, so not calling it would prevent
1267 both stopping and suspending thread from working.
1268 */
1269 virtual bool TestDestroy();
1270
1271 /**
1272 Return the thread object for the calling thread.
1273
1274 @NULL is returned if the calling thread is the main (GUI) thread, but
1275 IsMain() should be used to test whether the thread is really the main one
1276 because @NULL may also be returned for the thread not created with wxThread
1277 class. Generally speaking, the return value for such a thread is undefined.
1278 */
1279 static wxThread* This();
1280
1281 /**
1282 Waits for a @b joinable thread to terminate and returns the value the thread
1283 returned from Entry() or @c "(ExitCode)-1" on error. Notice that, unlike
1284 Delete(), this function doesn't cancel the thread in any way so the caller
1285 waits for as long as it takes to the thread to exit.
1286
1287 You can only Wait() for @b joinable (not detached) threads.
1288
1289 This function can only be called from another thread context.
1290
1291 @param flags
1292 As described in wxThreadWait documentation, wxTHREAD_WAIT_BLOCK
1293 should be used as the wait mode even although currently
1294 wxTHREAD_WAIT_YIELD is for compatibility reasons. This parameter is
1295 new in wxWidgets 2.9.2.
1296
1297 See @ref thread_deletion for a broader explanation of this routine.
1298 */
1299 ExitCode Wait(wxThreadWait flags = wxTHREAD_WAIT_BLOCK);
1300
1301 /**
1302 Give the rest of the thread's time-slice to the system allowing the other
1303 threads to run.
1304
1305 Note that using this function is @b strongly discouraged, since in
1306 many cases it indicates a design weakness of your threading model
1307 (as does using Sleep() functions).
1308
1309 Threads should use the CPU in an efficient manner, i.e. they should
1310 do their current work efficiently, then as soon as the work is done block
1311 on a wakeup event (wxCondition, wxMutex, select(), poll(), ...) which will
1312 get signalled e.g. by other threads or a user device once further thread
1313 work is available.
1314 Using Yield() or Sleep() indicates polling-type behaviour, since we're
1315 fuzzily giving up our timeslice and wait until sometime later we'll get
1316 reactivated, at which time we realize that there isn't really much to do
1317 and Yield() again...
1318
1319 The most critical characteristic of Yield() is that it's operating system
1320 specific: there may be scheduler changes which cause your thread to not
1321 wake up relatively soon again, but instead many seconds later,
1322 causing huge performance issues for your application.
1323
1324 <strong>
1325 With a well-behaving, CPU-efficient thread the operating system is likely
1326 to properly care for its reactivation the moment it needs it, whereas with
1327 non-deterministic, Yield-using threads all bets are off and the system
1328 scheduler is free to penalize them drastically</strong>, and this effect
1329 gets worse with increasing system load due to less free CPU resources available.
1330 You may refer to various Linux kernel @c sched_yield discussions for more
1331 information.
1332
1333 See also Sleep().
1334 */
1335 static void Yield();
1336
1337protected:
1338
1339 /**
1340 This is the entry point of the thread.
1341
1342 This function is pure virtual and must be implemented by any derived class.
1343 The thread execution will start here.
1344
1345 The returned value is the thread exit code which is only useful for
1346 joinable threads and is the value returned by Wait().
1347 This function is called by wxWidgets itself and should never be called
1348 directly.
1349 */
1350 virtual ExitCode Entry() = 0;
1351
1352 /**
1353 This is a protected function of the wxThread class and thus can only be called
1354 from a derived class. It also can only be called in the context of this
1355 thread, i.e. a thread can only exit from itself, not from another thread.
1356
1357 This function will terminate the OS thread (i.e. stop the associated path of
1358 execution) and also delete the associated C++ object for detached threads.
1359 OnExit() will be called just before exiting.
1360 */
1361 void Exit(ExitCode exitcode = 0);
1362
1363private:
1364
1365 /**
1366 Called when the thread exits.
1367
1368 This function is called in the context of the thread associated with the
1369 wxThread object, not in the context of the main thread.
1370 This function will not be called if the thread was @ref Kill() killed.
1371
1372 This function should never be called directly.
1373 */
1374 virtual void OnExit();
1375};
1376
1377
1378/** See wxSemaphore. */
1379enum wxSemaError
1380{
1381 wxSEMA_NO_ERROR = 0,
1382 wxSEMA_INVALID, //!< semaphore hasn't been initialized successfully
1383 wxSEMA_BUSY, //!< returned by TryWait() if Wait() would block
1384 wxSEMA_TIMEOUT, //!< returned by WaitTimeout()
1385 wxSEMA_OVERFLOW, //!< Post() would increase counter past the max
1386 wxSEMA_MISC_ERROR
1387};
1388
1389/**
1390 @class wxSemaphore
1391
1392 wxSemaphore is a counter limiting the number of threads concurrently accessing
1393 a shared resource. This counter is always between 0 and the maximum value
1394 specified during the semaphore creation. When the counter is strictly greater
1395 than 0, a call to wxSemaphore::Wait() returns immediately and decrements the
1396 counter. As soon as it reaches 0, any subsequent calls to wxSemaphore::Wait
1397 block and only return when the semaphore counter becomes strictly positive
1398 again as the result of calling wxSemaphore::Post which increments the counter.
1399
1400 In general, semaphores are useful to restrict access to a shared resource
1401 which can only be accessed by some fixed number of clients at the same time.
1402 For example, when modeling a hotel reservation system a semaphore with the counter
1403 equal to the total number of available rooms could be created. Each time a room
1404 is reserved, the semaphore should be acquired by calling wxSemaphore::Wait
1405 and each time a room is freed it should be released by calling wxSemaphore::Post.
1406
1407 @library{wxbase}
1408 @category{threading}
1409*/
1410class wxSemaphore
1411{
1412public:
1413 /**
1414 Specifying a @a maxcount of 0 actually makes wxSemaphore behave as if
1415 there is no upper limit. If @a maxcount is 1, the semaphore behaves almost as a
1416 mutex (but unlike a mutex it can be released by a thread different from the one
1417 which acquired it).
1418
1419 @a initialcount is the initial value of the semaphore which must be between
1420 0 and @a maxcount (if it is not set to 0).
1421 */
1422 wxSemaphore(int initialcount = 0, int maxcount = 0);
1423
1424 /**
1425 Destructor is not virtual, don't use this class polymorphically.
1426 */
1427 ~wxSemaphore();
1428
1429 /**
1430 Increments the semaphore count and signals one of the waiting
1431 threads in an atomic way. Returns @e wxSEMA_OVERFLOW if the count
1432 would increase the counter past the maximum.
1433
1434 @return One of:
1435 - wxSEMA_NO_ERROR: There was no error.
1436 - wxSEMA_INVALID : Semaphore hasn't been initialized successfully.
1437 - wxSEMA_OVERFLOW: Post() would increase counter past the max.
1438 - wxSEMA_MISC_ERROR: Miscellaneous error.
1439 */
1440 wxSemaError Post();
1441
1442 /**
1443 Same as Wait(), but returns immediately.
1444
1445 @return One of:
1446 - wxSEMA_NO_ERROR: There was no error.
1447 - wxSEMA_INVALID: Semaphore hasn't been initialized successfully.
1448 - wxSEMA_BUSY: Returned by TryWait() if Wait() would block, i.e. the count is zero.
1449 - wxSEMA_MISC_ERROR: Miscellaneous error.
1450 */
1451 wxSemaError TryWait();
1452
1453 /**
1454 Wait indefinitely until the semaphore count becomes strictly positive
1455 and then decrement it and return.
1456
1457 @return One of:
1458 - wxSEMA_NO_ERROR: There was no error.
1459 - wxSEMA_INVALID: Semaphore hasn't been initialized successfully.
1460 - wxSEMA_MISC_ERROR: Miscellaneous error.
1461 */
1462 wxSemaError Wait();
1463
1464 /**
1465 Same as Wait(), but with a timeout limit.
1466
1467 @return One of:
1468 - wxSEMA_NO_ERROR: There was no error.
1469 - wxSEMA_INVALID: Semaphore hasn't been initialized successfully.
1470 - wxSEMA_TIMEOUT: Timeout occurred without receiving semaphore.
1471 - wxSEMA_MISC_ERROR: Miscellaneous error.
1472 */
1473 wxSemaError WaitTimeout(unsigned long timeout_millis);
1474};
1475
1476
1477
1478/**
1479 @class wxMutexLocker
1480
1481 This is a small helper class to be used with wxMutex objects.
1482
1483 A wxMutexLocker acquires a mutex lock in the constructor and releases
1484 (or unlocks) the mutex in the destructor making it much more difficult to
1485 forget to release a mutex (which, in general, will promptly lead to serious
1486 problems). See wxMutex for an example of wxMutexLocker usage.
1487
1488 @library{wxbase}
1489 @category{threading}
1490
1491 @see wxMutex, wxCriticalSectionLocker
1492*/
1493class wxMutexLocker
1494{
1495public:
1496 /**
1497 Constructs a wxMutexLocker object associated with mutex and locks it.
1498 Call IsOk() to check if the mutex was successfully locked.
1499 */
1500 wxMutexLocker(wxMutex& mutex);
1501
1502 /**
1503 Destructor releases the mutex if it was successfully acquired in the ctor.
1504 */
1505 ~wxMutexLocker();
1506
1507 /**
1508 Returns @true if mutex was acquired in the constructor, @false otherwise.
1509 */
1510 bool IsOk() const;
1511};
1512
1513
1514/**
1515 The possible wxMutex kinds.
1516*/
1517enum wxMutexType
1518{
1519 /** Normal non-recursive mutex: try to always use this one. */
1520 wxMUTEX_DEFAULT,
1521
1522 /** Recursive mutex: don't use these ones with wxCondition. */
1523 wxMUTEX_RECURSIVE
1524};
1525
1526
1527/**
1528 The possible wxMutex errors.
1529*/
1530enum wxMutexError
1531{
1532 /** The operation completed successfully. */
1533 wxMUTEX_NO_ERROR = 0,
1534
1535 /** The mutex hasn't been initialized. */
1536 wxMUTEX_INVALID,
1537
1538 /** The mutex is already locked by the calling thread. */
1539 wxMUTEX_DEAD_LOCK,
1540
1541 /** The mutex is already locked by another thread. */
1542 wxMUTEX_BUSY,
1543
1544 /** An attempt to unlock a mutex which is not locked. */
1545 wxMUTEX_UNLOCKED,
1546
1547 /** wxMutex::LockTimeout() has timed out. */
1548 wxMUTEX_TIMEOUT,
1549
1550 /** Any other error */
1551 wxMUTEX_MISC_ERROR
1552};
1553
1554
1555/**
1556 @class wxMutex
1557
1558 A mutex object is a synchronization object whose state is set to signaled when
1559 it is not owned by any thread, and nonsignaled when it is owned. Its name comes
1560 from its usefulness in coordinating mutually-exclusive access to a shared
1561 resource as only one thread at a time can own a mutex object.
1562
1563 Mutexes may be recursive in the sense that a thread can lock a mutex which it
1564 had already locked before (instead of dead locking the entire process in this
1565 situation by starting to wait on a mutex which will never be released while the
1566 thread is waiting) but using them is not recommended under Unix and they are
1567 @b not recursive by default. The reason for this is that recursive
1568 mutexes are not supported by all Unix flavours and, worse, they cannot be used
1569 with wxCondition.
1570
1571 For example, when several threads use the data stored in the linked list,
1572 modifications to the list should only be allowed to one thread at a time
1573 because during a new node addition the list integrity is temporarily broken
1574 (this is also called @e program @e invariant).
1575
1576 @code
1577 // this variable has an "s_" prefix because it is static: seeing an "s_" in
1578 // a multithreaded program is in general a good sign that you should use a
1579 // mutex (or a critical section)
1580 static wxMutex *s_mutexProtectingTheGlobalData;
1581
1582 // we store some numbers in this global array which is presumably used by
1583 // several threads simultaneously
1584 wxArrayInt s_data;
1585
1586 void MyThread::AddNewNode(int num)
1587 {
1588 // ensure that no other thread accesses the list
1589 s_mutexProtectingTheGlobalList->Lock();
1590
1591 s_data.Add(num);
1592
1593 s_mutexProtectingTheGlobalList->Unlock();
1594 }
1595
1596 // return true if the given number is greater than all array elements
1597 bool MyThread::IsGreater(int num)
1598 {
1599 // before using the list we must acquire the mutex
1600 wxMutexLocker lock(s_mutexProtectingTheGlobalData);
1601
1602 size_t count = s_data.Count();
1603 for ( size_t n = 0; n < count; n++ )
1604 {
1605 if ( s_data[n] > num )
1606 return false;
1607 }
1608
1609 return true;
1610 }
1611 @endcode
1612
1613 Notice how wxMutexLocker was used in the second function to ensure that the
1614 mutex is unlocked in any case: whether the function returns true or false
1615 (because the destructor of the local object @e lock is always called).
1616 Using this class instead of directly using wxMutex is, in general, safer
1617 and is even more so if your program uses C++ exceptions.
1618
1619 @library{wxbase}
1620 @category{threading}
1621
1622 @see wxThread, wxCondition, wxMutexLocker, wxCriticalSection
1623*/
1624class wxMutex
1625{
1626public:
1627 /**
1628 Default constructor.
1629 */
1630 wxMutex(wxMutexType type = wxMUTEX_DEFAULT);
1631
1632 /**
1633 Destroys the wxMutex object.
1634 */
1635 ~wxMutex();
1636
1637 /**
1638 Locks the mutex object.
1639 This is equivalent to LockTimeout() with infinite timeout.
1640
1641 Note that if this mutex is already locked by the caller thread,
1642 this function doesn't block but rather immediately returns.
1643
1644 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_DEAD_LOCK.
1645 */
1646 wxMutexError Lock();
1647
1648 /**
1649 Try to lock the mutex object during the specified time interval.
1650
1651 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_DEAD_LOCK, @c wxMUTEX_TIMEOUT.
1652 */
1653 wxMutexError LockTimeout(unsigned long msec);
1654
1655 /**
1656 Tries to lock the mutex object. If it can't, returns immediately with an error.
1657
1658 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_BUSY.
1659 */
1660 wxMutexError TryLock();
1661
1662 /**
1663 Unlocks the mutex object.
1664
1665 @return One of: @c wxMUTEX_NO_ERROR, @c wxMUTEX_UNLOCKED.
1666 */
1667 wxMutexError Unlock();
1668};
1669
1670
1671
1672// ============================================================================
1673// Global functions/macros
1674// ============================================================================
1675
1676/** @addtogroup group_funcmacro_thread */
1677//@{
1678
1679/**
1680 This macro declares a (static) critical section object named @a cs if
1681 @c wxUSE_THREADS is 1 and does nothing if it is 0.
1682
1683 @header{wx/thread.h}
1684*/
1685#define wxCRIT_SECT_DECLARE(cs)
1686
1687/**
1688 This macro declares a critical section object named @a cs if
1689 @c wxUSE_THREADS is 1 and does nothing if it is 0. As it doesn't include
1690 the @c static keyword (unlike wxCRIT_SECT_DECLARE()), it can be used to
1691 declare a class or struct member which explains its name.
1692
1693 @header{wx/thread.h}
1694*/
1695#define wxCRIT_SECT_DECLARE_MEMBER(cs)
1696
1697/**
1698 This macro creates a wxCriticalSectionLocker named @a name and associated
1699 with the critical section @a cs if @c wxUSE_THREADS is 1 and does nothing
1700 if it is 0.
1701
1702 @header{wx/thread.h}
1703*/
1704#define wxCRIT_SECT_LOCKER(name, cs)
1705
1706/**
1707 This macro combines wxCRIT_SECT_DECLARE() and wxCRIT_SECT_LOCKER(): it
1708 creates a static critical section object and also the lock object
1709 associated with it. Because of this, it can be only used inside a function,
1710 not at global scope. For example:
1711
1712 @code
1713 int IncCount()
1714 {
1715 static int s_counter = 0;
1716
1717 wxCRITICAL_SECTION(counter);
1718
1719 return ++s_counter;
1720 }
1721 @endcode
1722
1723 Note that this example assumes that the function is called the first time
1724 from the main thread so that the critical section object is initialized
1725 correctly by the time other threads start calling it, if this is not the
1726 case this approach can @b not be used and the critical section must be made
1727 a global instead.
1728
1729 @header{wx/thread.h}
1730*/
1731#define wxCRITICAL_SECTION(name)
1732
1733/**
1734 This macro is equivalent to
1735 @ref wxCriticalSection::Leave "critical_section.Leave()" if
1736 @c wxUSE_THREADS is 1 and does nothing if it is 0.
1737
1738 @header{wx/thread.h}
1739*/
1740#define wxLEAVE_CRIT_SECT(critical_section)
1741
1742/**
1743 This macro is equivalent to
1744 @ref wxCriticalSection::Enter "critical_section.Enter()" if
1745 @c wxUSE_THREADS is 1 and does nothing if it is 0.
1746
1747 @header{wx/thread.h}
1748*/
1749#define wxENTER_CRIT_SECT(critical_section)
1750
1751/**
1752 Returns @true if this thread is the main one. Always returns @true if
1753 @c wxUSE_THREADS is 0.
1754
1755 @header{wx/thread.h}
1756*/
1757bool wxIsMainThread();
1758
1759
1760
1761/**
1762 This function must be called when any thread other than the main GUI thread
1763 wants to get access to the GUI library. This function will block the
1764 execution of the calling thread until the main thread (or any other thread
1765 holding the main GUI lock) leaves the GUI library and no other thread will
1766 enter the GUI library until the calling thread calls wxMutexGuiLeave().
1767
1768 Typically, these functions are used like this:
1769
1770 @code
1771 void MyThread::Foo(void)
1772 {
1773 // before doing any GUI calls we must ensure that
1774 // this thread is the only one doing it!
1775
1776 wxMutexGuiEnter();
1777
1778 // Call GUI here:
1779 my_window->DrawSomething();
1780
1781 wxMutexGuiLeave();
1782 }
1783 @endcode
1784
1785 This function is only defined on platforms which support preemptive
1786 threads and only works under some ports (wxMSW currently).
1787
1788 @note Under GTK, no creation of top-level windows is allowed in any thread
1789 but the main one.
1790
1791 @header{wx/thread.h}
1792*/
1793void wxMutexGuiEnter();
1794
1795/**
1796 This function is only defined on platforms which support preemptive
1797 threads.
1798
1799 @see wxMutexGuiEnter()
1800
1801 @header{wx/thread.h}
1802*/
1803void wxMutexGuiLeave();
1804
1805//@}
1806