Can anyone help me write a practical example of MFC multithreading, thanks

I prefer to use multi-threading, and the simplest way to do it is to be efficient, for example, we only use one main thread in a program, and we are doing one thing at a time; And if we open up multiple threads, we can do multiple things at the same time without interfering with each other, and each of us can do our own work.

Multi-threading is like a multi-tasking operating system, we can listen to both ** and surf the Internet at the same time, and single-threaded is like single-tasking, we need to listen to ** and then go online, so it takes a lot longer.

For example, if your program needs to constantly update a certain piece of data, then you can open up a thread for it, and let it loop indefinitely to perform updates in the background every once in a while, while the main thread is still interacting with the user non-stop, isn't it convenient to have a thread?

That's how I understand it.

There is another place where threads are more general, for example, in our program, there is a function that is more time-consuming, such as reading information in a huge database and calculating the data, which is more time-consuming, then we have to open up a thread for it, let it work in the background, when the main thread is doing other things with the user, this thread will quietly process the data from the background, so that the user does not have to wait, and does not feel that your program is running slowly; Usually more than 5 seconds of waiting time will open a thread for it.

That's all there is to it

This should be a network program...

Indeed, it is possible to use the asynchronous network communication mode without multi-threading, which will not block the land while waiting for the data to be received, and also save the trouble of thread synchronization. It's just that the example you mentioned uses multi-threading to write a field is a little simpler, ** blocking the receiving message in the program, and a thread processes a fixed person's message, and the structure is simple.

For Song Zhentong's single-core computer, there is only one thread running at each point in time, and the CPU keeps switching threads so that each thread has a chance to run.

Nowadays, computer multi-core is very common, multi-threading can give full play to the efficiency of the CPU, and multiple threads can be run by multiple CPU cores at the same time, which is faster.

Write a thread function with the following parameters and return values.

uint threadtest(lpvoid pparam);

Then start the thread directly in the button with the following function.

afxbeginthread(threadtest,null);

Where the data will be processed, create a thread using afxbeginthread, which is simply an MFC enclosed global function, you can look it up and note that the procedure function must be static or global. The data is then passed to the procedure function via the parameters of the afxbeginthread for processing. As for the calculated results.

It is recommended that you use the method of sending msg notifications to the main window.

MFC thread creation function: afxbeginthreadwin32 thread creation function: createthreadcrt thread creation function:

BeginThread Beginthreadex can be used in all three ways.

The best solution to be a server under Windows is iocp (i o complete port), Chinese name i o complete port.

The performance is very good. When it comes to Windows advanced programming, the difficulty index is relatively high.

You feel good that this solution is not feasible :

1.A lot of CPU time will be wasted. A computer has a limited number of CPUs, if your computer only has 2 CPUs, but 200 threads are open.

At this time, there are up to 2 threads running at the same time (because you only have 2 CPUs), but the constant switching of threads makes you feel as if all 200 are running, but slowly. (At this time, thread switching will consume a lot of CPU time, and the gains outweigh the losses).

2.Waste of memory. Threads need to be represented by data in Windows, 200 threads, the overhead is a bit wasteful (although the memory is very large now, but we can't waste it).

3.Thread synchronization issues will make you dizzy, 200 threads concurrent processing is troublesome, to do thread synchronization, as well as thread communication, synchronization and communication is something that multithreads must think through.

4.There's a pretty good solution --- iocp

There are a lot of online materials about the study of IOCP, and I won't say much about it here.

enjoy coding

The problem description is not clear, the second floor is good, and the knowledge is long.

Using the suspendthread() and resumethread() functions, you can suspend and wake up a thread, which can be called by another thread or by itself.

Sleep is also known as the sleep() function or sleepex function upstairs, which is just a specified period of events that temporarily suspend the thread for interaction with the user. Of course, hibernation is also suspended, and this suspension time is indefinite, and resumethread() is required.

At the end of the day, hibernation and sleep are suspended, it's just a matter of uncertain timing and whether you need to wake up. Sleep needs to be woken up by threads, and when the time for sleep is up, you wake up by yourself, that's the difference!

First of all, I would like to emphasize one point: you have the main thread and the new thread here, they all exist in the process of your program, this problem does not involve the main process, the child process or anything, and the concept of process and line world must not be confused.

Even if the sleep function is not used for the new thread, the UIS still cannot respond to the operation of updating the UI in the new thread. Windows threads can be divided into UI threads and worker threads, the main thread is the UI thread, responsible for all human-computer interaction work that responds to user input and drawing window interfaces, and the newly created thread is a worker thread, which is only responsible for computing and does not deal with human-computer interaction. So when to respond to the update of the interface is determined by your main thread, if the main thread is still executing a function and does not return to the message loop, it cannot update the interface, and when the function is executed, the interface can be updated.

Preventing threads from being interrupted is a thread synchronization issue, and has nothing to do with the problem here. Windows provides a range of thread synchronization APIs, you can use user-level thread synchronization APIs such as spinlocks, critical regions, slim read-write locks, conditional variables, or kernel synchronization objects using events, semaphores, mutexes, etc. The specific principles and usage methods can not be explained clearly in a few words, you can read the operating system teaching pure materials and the chapter on multi-threading in "Windows Core Programming".