Multi-threading programming for assembly tutorials

In this lesson, we'll learn how to do multithreaded programming. In addition, we will learn how to communicate between different threads.

Theory:

In the previous lesson, we learned about processes in which each process had at least one main thread. This thread is actually a clue to the execution of the process, and in addition to this main thread you can add additional threads to the process, or add other execution leads, which can be viewed in some way as adding multitasking capabilities to an application. When the program is running, you can suspend or run these threads based on various conditions, especially in a multiple-CPU environment where these threads are running concurrently. These are the concepts that are W32 under the WIN16, and there is no equivalent concept under it.

The benefit of running different threads in the same process is that these threads can share the resources of the process, such as global variables, resources, and so on. Of course, each thread can also have its own private stack for storing private data. In addition, each thread needs to save its run context so that it can remember or restore its context when the thread switches, of course, it is done by the operating system and transparent to the user.

We can basically divide threads into two broad categories:

The thread that handles the user interface: the thread produces its own window and is responsible for processing related window messages. The user interface thread adheres to the mutex principle under WIN16, that is, there is not a moment. Only one user interface thread uses kernel functions in user and GDI libraries, meaning that the kernel does not allow reentrant when a user interface program enters GDI or user. From this we can deduce that the code for this part of the WIN95 is compliant with the 16-bit pattern. And Winows NT is a pure 32-bit operating system, so there is no such problem.

Worker threads: This thread does not need to handle the window interface, and of course it does not have to process the message. It generally runs in the background to do some calculations such as rough, which is probably the reason to call it worker threads.

Using W32 multithreaded mode to program, we can follow a strategy that lets the main thread only do the work of the user interface, while the other heavy work is done by the worker thread in the background. This is like a lot of examples in our daily life. For example, government managers, like user interface threads, are responsible for listening to public opinion, assigning jobs to functional departments, and then reporting the results to the public. and the specific functional department is worker thread, it is responsible for the completion of the specific work assigned. If the government manages this to do everything concretely, it must do one thing after another, and it will not be able to hear and feed back the public opinion in time. This will not be able to manage a good country. Of course, even if the use of multithreading, the Government management department is not necessarily able to manage the country, but the program can use multithreading mechanism to manage her own work. We can call the CreateThread function to generate a new thread. The syntax for this function is as follows:

CreateThread proto lpThreadAttributes:DWORD,\
dwStackSize:DWORD,\
lpStartAddress:DWORD,\
lpParameter:DWORD,\
dwCreationFlags:DWORD,\
lpThreadId:DWORD

A function that generates a thread is essentially the same as generating a process.

Lpthreadattributes--> If you want the thread to have the default security attribute, you can set the value to null.

Dwstacksize--> The stack size of the specified thread. If 0, the thread is the same size as the process.

Lpstartaddress--> The starting address of the thread function. Note that the function receives only a 32-bit argument and returns a 32-bit value. (This parameter can be a pointer, and the thread of the process can directly access the process to define global variables, so you don't have to worry about how to pass a large number of arguments to the thread).

Lpparameter--> is passed to the thread's context.

dwCreationFlags--> If it is 0, it will start immediately after the creation line Chengjian, instead of the flag bit create_suspended so that you need to display the thread later to run it.

Lpthreadid the thread ID that the--> kernel assigns to the newly generated thread.

If the generated line Cheng, the CreateThread function returns the handle to the new thread. Otherwise null is returned.

If you do not specify create_suspended for the parameter dwcreationflags, the thread will run immediately. If not, as we said above, you need to display to start the thread, and to do so you need to call the ResumeThread function.

After the thread returns (the execution of the threads resembles and executes a function, if it calls the last instruction, and it is a RET in the assembly, then the thread ends unless you let it into a loop, such as the user interface thread we are talking about, except that it does not exit because the loop is entered in the {while ( GetMessage (.....) ）)...} , if you do not pass it a message with a value of 0, it will not exit, and the ExitThread function is automatically invoked to transparently handle some cleanup of the thread when it exits. Of course you can call the function yourself, but it doesn't seem to make any sense. To get the exit code at exit time, you can call the GetExitCodeThread function.