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