Win32 multi-threaded program design learning notes (Chapter 4 below)
Finally, I finally read the << Win32 multi-threaded program design >>; open rolls, today I saw the second half of the fourth chapter, I feel quite gain; I used to be the core object of Event, I used to always I didn't have the bottom, I saw Event. The introduction is also like understanding. what! After watching it today, I really have God, I think it should be to understand (think about it J). Think carefully, it should be the credit of notes, it is really not easy to forget the things written in my own brains! ! ! Not only impressive, but also helps me understand Event.
Ok, gossip less, enter the topic!
Since the third chapter, each chapter must be indispensable for an important function. Do you know what it is?
---- Waitfor .... () Series
// Quick review
Judging whether a thread ends: WaitforsingleObject (Handle Hthred ....);
Determine if it is possible to enter the critical area: WaitforsingleObject (hmutex ....);
Wait .... () Will return when the core object is excited, various core objects are not very different, for hthred, the thread ends, means that the core object is excited; for hmutex, hmutex is no longer Other threads use, means that the core object is excited. Anyway, for a variety of core objects, it must be that there is a certain scene that causes the core object to be excited, except for the core object of Event.
For Event This core object, its excitation state is completely controlled by the program, that is, controlling Event's excitation or unstimed state (by setEvent (), resetEvent ()). When thread 1 is blocked by calling Wait ... (HEVENT), it must be a thread to call the set to make HEVENT to stimulate, so that the thread 1 is released to continue to run down, and the specific application see The following table:
Function EVENT Object [Manual Mode Generation] EVENT Object [Auto Way Generated] Wait ... () When the EVENT object becomes an excitation state (so that the thread waits for Wait ... () is waken after waking up), it will not be reset to not be reset. Excited state (must call resetEvent ())
When the EVENT object becomes an excitation state (so that the thread waits for Wait ... () is woken up, it is automatically reset to non-excited state.
SetEvent () Set the EVENT object to the excitation state Set the EVENT object to the excitation state resetEvent () Set the EVENT object to the non-amplifiable state set the EVENT object to the non-arranging state PulseEvent () set the Event object to an excitation state, wake up " "Wait for the thread, then set the Event object to the non-amplifiable state to set the Event object to an excitation state, wake up" a "waiting in the thread, then set the Event object to an uncomfortable state.
[Use the CreateEvent () API function constructed Event core object, the second parameter of CreateEvent () determines whether the generated EVENT object is a manual or auto (automatic) mode; the third parameter determines the generated Event Object The initial state is stimulated or not excited]
EVENT core objects (initial status is excited or unbunned) and different types (Manual] or auto [Auto]), the corresponding processing method is different, there are too many cases, no For example, I will make up J (in Chapter 5 below, I got an example)
It is worth noting that requests that use the PulseEvent () method to excitation Event may be lost, and a series of issues that may be generated have a very exciting description in P124, which is worth seeing (thus describes the Semaphore synchronization mechanism). At this point, the fourth chapter can be almost over (except for semaphore, interlocked, look at it!)
Below you will enter the fifth chapter:
How to force a thread? Check out the API function of the thread, immediately find a function of ending the thread ---- TerminateTHREAD (); use it?
Oh! Don't use it. Threads that have been enforced by TerminateThread () may have the following consequences:
1. There is no chance to release the resources you use before you end.
2, may cause memory leakage
3. If this thread is in a critical section, then the critical section will thus always be locked.
So how do you force a thread? An example is given in the book, and it will be enforced with a thread later.
Program fragment:
// thread exits event
Handle Hexitevent = NULL;
// A thread that needs to run for a long time
DWORD WINAPI THREADFUN (LPVOID P)
{
For (int i = 0; i <1000000; i )
{
/ / Judgment whether the thread is to be enforced
/ * Maybe everyone is a bit doubtful, if there is no way to call setEvent (),
HEXITEVENT is not induced? Which line will not stop here?
The answer is: A Wait ... mentioned here for P74 is used. () A usage, when Time_OUT
0, check the state of Hexitevent, if Hexitevent is inactive,
Return to Wait_Timeout immediately if hexitevent is in motion, immediately
Returns WAIT_OBJECT_0. * /
IF (WaitforsingleObject (HEXITEVENT, 0)! = Wait_timeout)
{
// Do some cleaning work before exiting the thread
Return (DWORD) -1;
}
// Do some extremely time-consuming processing ....
// .......
// ...... ...
}
}
void main ()
{
Handle hthrd;
/ / Construct an EVENT core object, the initial state is in an unstimed state, the manual method
HEXITEVENT = CreateEvent (NULL, TRUE, FALSE, NULL);
// thread start
Hthrd = Createthread (null, threadfun); ....);
// Waiting for a long time, really can't go, issue an end thread to exit event (excited Event core object)
/ / Forcing threads to end
STEVENT (HEXITEVENT);
// Waiting for thread ends
WaitforsingleObject (hthrd, ...);
CloseHandle (HTHRD);
}
The following will then talk about the priority of the thread, adjusting the thread priority is very simple, nothing more than a function of setthreadpriority () and getthreadpriority (). But how to be effective, reasonable adjustment thread is a complex problem, as mentioned in the book, "If your goal is simple, then avoid processing [priority] this hot mantra."
