Multithreading in Microsoft Windows

In C/S Mode of Microwindows, the server and client need to communicate. Program If it is multi-threaded, we need to consider many aspects. 1. Does Microwindows support multithreading? 2. How does Microwindows handle display in multiple threads.

First of all, we can be certain that Microwindows supports multithreading, but we only need to add the threadsafe option during configuration so that we can use multithreading. Secondly, in my opinion, the functions provided by Microwindows are nothing more than the functions of the read server and the write server. For functions without return types such as void grxxx (), the server is written, and for grxxx () Functions with return values, the server is read, otherwise, no return value is required. The threadsafe option can be added during the configuration to ensure that multiple threads can be synchronized when reading and writing the server, so that you do not have to write a little bit. I write a little bit, which is messy.

The grgetnextevent function requires special attention. I am stuck here when writing multiple threads. In the grgetnextevent function, a global mutex is used for synchronization. Then, the system waits for the event to come and unlocks it when it comes. The problem arises. What if the thread created earlier needs to write to the server (for example, display )? Through the source code, we can find that this type of function in this thread checks whether global mutex can be locked. If not, it indicates that a function has been locked but has not been unlocked, this function is waiting. In this case, grgetnextevent has been locked but not unlocked. Therefore, if two threads are stuck here, grgetnextevent waits for the event, while the real process waits for grgetnextevent or event. To solve this problem, the grregisterinput function is used to register one character descriptor first in the grgetnextevent process in the main thread. This function is used to generate a gr_event_type_fdinput message when something in the file that has registered this descriptor is written (using the write function. Back to the scenario above, we can create pipelines in two threads to use them as registration descriptors.

Int pipeinitial ()
{
Int ret;

Unlink ("/tmp/ABC ");
Ret = mkfifo ("/tmp/ABC", s_ififo | 0666 );
If (ret =-1)
{
Pdebug ("cann' t make FIFO/N ");
Return-1;
}
Pipe_fd = open ("/tmp/ABC", o_rdwr );

Grregisterinput (pipe_fd );
Return 0;
}
In the above function, the grregisterinput registration is called after the MPs queue is created.

Put the display function in the thread that requires the display in the main thread, that is, switch.
Switch {
Case gr_event_type_fdinput:
The displayed function;
Pthread_cond_signal (& Cond); // The Notification thread displays that it has ended.
Break;
.....
}
Of course, you can use synchronization when necessary to solve the problem of synchronization between the display and the next thread.

In the next thread, open the pipeline open (pipe_fd, o_rwonly)
Add
Char c = 'C ';
Write (pipe_fd, C, 1 );
Pthread_mutex_lock (& mutex );
Pthread_cond_wait (& cond, & mutex );
Pthread_mutex_unlock (& mutex );
The last three statements are used to wait until the display ends.

This solves this problem. Smile a few times on the day, these days in order to be able to smoothly as soon as possible the elegant resignation, I have been greedy for writing E-BOOKCodeI finally finished it today. I hope I can get a proof of resignation tomorrow.