Using multiple cores within a single thread in C++ and MFC

[TQTL]

I have a question for making use of multiple cores within a single thread. The scenario is like this, I need to do an intensive analysis behind the scene, so I create a separate thread to do this. As I want this thread to use multiple cores if they are available, OpenMP is used within this thread. Does this thread actually use multiple cores available? I guess it does, then my next question is how to kill this thread safely? i.e. anything needs to take care of compare with single core case? Why I am asking this question is that the killing process crashes the application when nultiple cores are used

[Lost User]

TQTL wrote:

the killing process crashes the application when nultiple cores are used

Sorry, but it is impossible to view your code from out here.

[Patrice T]

The rule is: maximum of 1 core per thread. You have to design your program for multi-threading, then launch as many thread as you want, they will spread across cores until you reach the number of cores, after that, some threads will share the same core.

Patrice “Everything should be made as simple as possible, but no simpler.” Albert Einstein

[Lost User]

Hi, I countered the unwarranted downvote. The question is not low quality. Have a look at Parallel Programming in Visual C++[^] and make sure you read everything. Some thoughts: 1.) Yes, these parallelization libraries take advantage of multiple cores. 2.) Some of the libraries may be using Fibers[^] under the hood. 3.) Each library has a different technique for breaking out of the parallelized algorithm. For example... the concurrency namespace[^] utilizes a cancellation_token[^] while the OpenMP library uses the #pragma omp cancel[^] Your Crash: If you are experiencing a crash while using the Microsoft implementation of OpenMP... its probably because the OpenMP cancel directive is not supported. Microsoft only supports a partial subset of the directives[^]. As you can see... cancel is not in the list of supported directives. If you are *not* using the Microsoft implementation of OpenMP then you probably need to #define OMP_CANCELLATION as the cancel directive is typically disabled for performance reasons. Best Wishes, -David Delaune P.S. If you want to convert your code from OpenMP to the Microsoft concurrency runtime[^] then here is an example.

[David Crow]

TQTL wrote:

...how to kill this thread safely?

With few exceptions, this is generally a bad idea. A thread can internally kill itself, but that is a different question.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

[leon de boer]

Just ask OpenMP how many processors it is using

int omp_get_num_procs();

If you want the answer from windows

SYSTEM_INFO sysinfo;
GetSystemInfo(&sysinfo);
int countCPU = sysinfo.dwNumberOfProcessors;

If you are expecting it to make MFC itself quicker it won't by very much at all unless it's just particular things like graphics or file access that is slowing you down. To explain why we need to look at MFC which is an event drive system, meaning it fetches messages and dispatches messages that is it's basic behaviour. Part of that behaviour is it needs the events to process in the order they are in the message queue. For example clicking on the X close button on the top of an application fires off 3 messages WM_CLOSE WM_DESTROY WM_QUIT Those messages must be processed in that order and the next message can not be started to process until the one before it is completed. So the required ordering of processing of the event queue trumps any multiprocessor threading you want to put on the message queue. Even things like WM_PAINT messages are in order you must paint the windows in that order. It's pretty safe to say most things in the message queue except probably things like WM_MOUSEMOVE are going to have a required order to them and multithreaded or not you can't process the next message without the previous completing. So you can't really speed the MFC message framework up. The things you can speed up is the single processing of a single message. So in response to a WM_XXXXXXX message you may spawn threads to achieve the required task that is to be executed on that message in a faster time. If what you are doing is safe to windows it is safe to MFC because your threads will all end at exactly the same point as a single threaded program and you will either send back a LRESULT, Send/Post off a message or do some action and MFC would be unaware of the threads. So basically if you multithread within a single message process or within an action or process that is called you can do it safely from MFC point of view and in fact MFC would be oblivious to the threading. If you are having problems and crashing you are either not containing yourself to those guidelines and creating order problems for MFC or alternatively what you are doing is just broken on windows and the problem has nothing to do with MFC. You can split an join threads just using C++11, make a windows console application and paste this code in to see that and mutexing stuff to control. Your OpenMP etc should gi