Menu
I'm working on a program that processes many requests, none of them reaching more than 50% of CPU (currently I'm working on a dual core). So I created a thread for each request, the whole process is faster. Processing 9 requests, a single thread lasts 02min08s, while with 3 threads working simultaneously the time decreased to 01min37s, but it keeps not using 100% CPU, only around 50%.
How could I allow my program to use full processors capability?
EDIT The application isn't IO or Memory bounded, they're at reasonable levels all the time.
I think it has something to do with the 'dual core' thing.
There is a locked method invocation that every request uses, but it is really fast, I don't think this is the problem.
The more cpu-costly part of my code is the call of a dll via COM (the same external method is called from all threads). This dll is also no Memory or IO-bounded, it is an AI recognition component, I'm doing an OCR recognition of paychecks, a paycheck for request.
EDIT2
It is very probable that the STA COM Method is my problem, I contacted the component owners in order to solve this problem.
836
C does not contain any built-in support for multithreaded applications. Instead, it relies entirely upon the operating system to provide this feature. This tutorial assumes that you are working on Linux OS and we are going to write multi-threaded C program using POSIX.
A multithreaded program contains two or more parts that can run concurrently. Each part of such a program is called a thread, and each thread defines a separate path of execution. Before C++ 11, there is no built-in support for multithreaded applications.
Starting with C++11 C++ has classes for multithreading support. The class you might be interested in most is std::thread . There are also classes for synchronization like std::mutex .
C++ multithreading involves creating and using thread objects, seen as std::thread in code, to carry out delegated sub-tasks independently. New threads are passed a function to complete, and optionally some parameters for that function.
Multithreading in C. For example, in a browser, multiple tabs can be different threads. MS word uses multiple threads, one thread to format the text, other thread to process inputs, etc. Threads operate faster than processes due to following reasons: 1) Thread creation is much faster. 2) Context switching between threads is much faster.
You're right that many programmers don't bother decomposing their systems so that they can profit from multiple threads of execution. Therefore the customer sees a benefit mainly from OS multiprogramming rather than program multi-thread execution.
Thread-based multitasking deals with the concurrent execution of pieces of the same program. A multithreaded program contains two or more parts that can run concurrently. Each part of such a program is called a thread, and each thread defines a separate path of execution. C does not contain any built-in support for multithreaded applications.
It literally makes the program stops in order to wait for the end of the selected thread. Doing multiple operations on one target at the same time is very dangerous, the best example I can give is for databases. If three threads want to write a single file at the same time, it would be a problem because an hard drive can't go as fast as a CPU does.
Do you have significant locking within your application? If the threads are waiting for each other a lot, that could easily explain it.
Other than that (and the other answers given), it's very hard to guess, really. A profiler is your friend...
EDIT: Okay, given the comments below, I think we're onto something:
The more cpu-costly part of my code is the call of a dll via COM (the same external method is called from all threads).
Is the COM method running in an STA by any chance? If so, it'll only use one thread, serializing calls. I strongly suspect that's the key to it. It's similar to having a lock around that method call (not quite the same, admittedly).
178
The problem is the COM object.
Most COM objects run in the context of a 'single-threaded apartment'. (You may have seen a [STAThread] annotation on the main method of a .NET application from time to time?)
Effectively this means that all dispatches to that object are handled by a single thread. Throwing more cores at the problem just gives you more resources that can sit around and wait or do other things in .NET.
You might want to take a look at this article from Joe Duffy (the head parallel .NET guy at Microsoft) on the topic.
http://www.bluebytesoftware.com/blog/PermaLink,guid,8c2fed10-75b2-416b-aabc-c18ce8fe2ed4.aspx
In practice if you have to do a bunch of things against a single COM object like this you are hosed, because .NET will just serialize access patterns internally behind your back. If you can create multiple COM objects and use them then you can resolve the issue because each can be created and accessed from a distinct STA thread. This will work until you hit about 100 STA threads, then things will go wonky. For details, see the article.
22
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
