I must say I know a lot of things about threads, but theres something that is driving me crazy.
I use to wait for a thread using the Windows API function WaitForSingleObject and it works fine. But, when i am debugging my code, it seems that WaitForSingleObject is very, very, very slow (it hangs a lot). But when I am just running my app without debug, WaitForSingleObject is very, very fast.
Why does this happen? Is it because of Messages that the IDE sends? Or is it because of the compiler?
This is not affecting me a lot. I just think this issue is really annoying.
Edit: I am using Delphi 2010.
I really doubt that WaitForSingleObject is in fact the ONLY thing that gets slower. Rather, it is probable that almost everything gets slower, when you run with debugging on.
I find that far more than Win32 API calls, calls to OutputdebugString slow me down, and anything that the IDE chooses to log in the event view, really, because a big load of these event or output messages, slows the IDE, the debugger, and thus the program that I'm debugging, a lot.
Try turning off the event view checkboxes in the configuration menu and see if EVERYTHING gets faster.
It's in Tools -> Options, as shown by the OP in his image, which I've also added here, for handy access:
Add more ram :) you probably have a not so powerful machine. I had a similar problem but using vs2010. Anyway the principles are the same: Running in debug mode adds an overhead from the checks added by compiler to the code and move overhead from the environment itself that must manages threads, resources and stuff for the case you want to see them.
PS: What makes you think the problem are the Wait* functions ? Have you made a simple application that use Wait* and behaves the same ?
Related
I am relatively new to IntelliJIdea. I am running version Ultimate 2019.2.
I am doing a multi-threaded debugging and it seems like IntelliJ suspends all threads once one of the breakpoints got hit. This means, at a given time I can work with one breakpoint only, I do not have the visibility into how my multi-threaded app is behaving.
In Eclipse I would see all suspended threads and I could've worked with any breakpoint I wished in any of suspended threads.
How can I configure smth like that in IntelliJ?
I have seen that I can select a breakpoint and then select a behavior for it: stop all threads or stop only a thread on which it was invoked. That's nice.
But I do have several dozens of breakpoints and I do not want to go back and change that behavior for each breakpoint separately. Can I configure this behavior globally??
Pls, advise. This is super annoying.
Alright, I have figured it out: when changing suspension behavior for a given breakpoint, there is a button Make Default that allows setting this behavior for all new breakpoints created after the change. Breakpoints created before the change will have their behavior unchanged.
I have been asked to debug, and improve, a complex multithreaded app, written by someone I don't have access to, that uses concurrent queues (both GCD and NSOperationQueue). I don't have access to a plan of the multithreaded architecture, that's to say a high-level design document of what is supposed to happen when. I need to create such a plan in order to understand how the app works and what it's doing.
When running the code and debugging, I can see in Xcode's Debug Navigator the various threads that are running. Is there a way of identifying where in the source-code a particular thread was spawned? And is there a way of determining to which NSOperationQueue an NSOperation belongs?
For example, I can see in the Debug Navigator (or by using LLDB's "thread backtrace" command) a thread's stacktrace, but the 'earliest' user code I can view is the overridden (NSOperation*) start method - stepping back earlier in the stack than that just shows the assembly instructions for the framework that invokes that method (e.g. __block_global_6, _dispatch_call_block_and_release and so on).
I've investigated and sought various debugging methods but without success. The nearest I got was the idea of method swizzling, but I don't think that's going to work for, say, queued NSOperation threads. Forgive my vagueness please: I'm aware that having looked as hard as I have, I'm probably asking the wrong question, and probably therefore haven't formed the question quite clearly in my own mind, but I'm asking the community for help!
Thanks
The best I can think of is to put breakpoints on dispatch_async, -[NSOperation init], -[NSOperationQueue addOperation:] and so on. You could configure those breakpoints to log their stacktrace, possibly some other info (like the block's address for dispatch_async, or the address of the queue and operation for addOperation:), and then continue running. You could then look though the logs when you're curious where a particular block came from and see what was invoked and from where. (It would still take some detective work.)
You could also accomplish something similar with dtrace if the breakpoints method is too slow.
I'm using 3.9.7 cURL library to download files from the internet, so I created a dynamic bibioteca of viculo. dll written in C using VC + + 6.0 the problem is that when either I call my function from within my vb6 application window locks and unlocks only after you have downloaded the file how do I solve this problem?
The problem is that when you call the function from your DLL, it "blocks" your app's execution until it gets finished. Basically, execution goes from the piece of code that makes the function call, to the code inside of the function call, and then only comes back to the next line after the function call after the code inside of the function has finished running. In fact, that's how all function calls work. You can see this for yourself by single-stepping through your code in the VB 6 development environment.
You don't normally notice this because the code inside of a function being called doesn't take very long to execute before control is returned to the caller. But in this case, since the function you're calling from the DLL is doing a lot of processing, it takes a while to execute, so it "blocks" the execution of your application's code for quite a while.
This is a good general explanation for the reason why your application window appears to be frozen. A bit more technically, it's because the message pump that is responsible for processing user interaction with on-screen elements is not running (it's part of your code that has been temporarily suspended until the function that you called finishes processing). This is a bit more difficult for a VB programmer to appreciate, since none of this nitty-gritty stuff is exposed in the world of VB. It's all happening behind the scenes, just like it is in a C program, but you don't normally have to deal with any of it. Occasionally, though, the abstraction leaks, and the nitty-gritty rears its ugly head. This is one of those cases.
The correct solution to this general problem, as others have hinted at, is to run lengthy operations on a background thread. This leaves your main thread (right now, the only one you have, the one your application is running on) free to continue processing user input, while the other thread can process the data and return that processed data to the main thread when it is finished. Of course, computers can't actually do more than one thing at a time, but the magic of the operating system rapidly switching between one task and another means that you can simulate this. The mechanism for doing so involves threads.
The catch comes in the fact that the VB 6 environment does not have any type of support for creating multiple threads. You only get one thread, and that's the main thread that your application runs on. If you freeze execution of that one, even temporarily, your application freezes—as you've already found out.
However, if you're already writing a C++ DLL, there's no reason you can't create multiple threads in a VB 6 app. You just have to handle everything yourself as if you were using another lower-level language like C++. Run the C++ code on a background thread, and only return its results to the main thread when it is completely finished. In the mean time, your main thread is free.
This is still quite a bit of work, though, especially if you're inexperienced when it comes to Win32 programming and the issues surrounding multiple threads. It might be easier to find a different library that supports asynchronous function calls out-of-the-box. Antagony suggests using VB's AsyncRead method. That is probably a good option; as Karl Peterson says in the linked article, it keeps everything in pure VB 6 code, which can be a real time saver as well as a boon to future maintenance programmers. The only problem is that you'll still have to process the data somehow once you obtain it. And if that's slow, you're right back where you started from…
Check out this article, which demonstrates how to asynchronously transfer large files using a little-known method in user controls.
I have a multi-threaded application that I'm debugging inside the IDE (Visual Studio 2008, Win7-64, C++).
For "debugging" purposes, I "pretend" that I always have a single processor (the program detects the number of local processors), but the program design establishes a minimum of two threads (e.g., the "main thread" which handles GUI and event traffic, and a second "processing" thread where work is moved off of the "main thread"). (In a "production" build there would be a single main thread, and one-or-more "processing" threads depending on the number of detected processors.)
ISSUE: Breakpoints in the code (within the IDE) sometimes are triggered, and sometimes not. Re-running the program may "catch" on a break point where the previous run it did not "catch" (no source code changes or rebuild is performed to see this change-in-breakpoint-catch-behavior, the program execution path is identical).
(I mostly only care about triggering breakpoints in the non-GUI/non-main-thread, but I assume that should not matter.)
QUESTION: Is there a way to make these break points catch more "reliably"? (What influences whether a break point "catches" or not?)
I'm aware of, and NOT concerned with the following:
Source is out-of-sync with latest linked executable
Build is not "debug" (no debug symbols available)
"Clean build" is needed (debug artifacts out-of-date)
"Step Over/Into" may not work properly when another thread "breaks"
during that first thread's stepping operation
On web searches, there was a mention of possibly setting the compiler setting to "x86" and not "Any Processor" to catch breakpoints, not sure why that might matter ... ?
Finally, yes, of course, all logic "should" be tested in a single-threaded application (e.g., re-factor to ensure deterministic single-threaded execution for unit and regression tests). However, for the current testing, I need to be in the "real" application (think "integration testing" or "systems integration").
Normally breaking is extremely reliable. Here are some things to try:
Hard code a breakpoint with DebugBreak(). This should always be caught, but if this exhibits the same broken behavior, you have narrowed down the problem.
Where you currently have the bp set, add a line to print to screen/file, and set the breakpoint on that line. This is to be certain this line is really even being hit. You may have a strange, unexpected bug that is actually skipping the entire section unexpectedly and this is necessary to be sure.
Try with and without any optimizations. Debugging works best with all optimizations off, but even with deadstripping and inlining features at work, breakpoints are expected to still work. Does this issue occur even with optimizations off?
You say ISO C++, does this mean you've actually switched off all microsoft extensions? I've never compiled this way in visual studio, but if you have, try switching extensions back on and see if that has any effect.
I'm going to agree with VoidStar and other comments. I have worked with VC6, VS2005, VS2008 and VS2010 and I have debugged pretty complex multi-threaded apps with them and breakpoints have always been reliable for me.
With once exception. For projects that use DLLs, sometimes breakpoints that are set in code from a DLL do not work. This is not because VS misses the breakpoint, but instead because the debugger cannot map that line of code to an actual location in the compiled code, probably because the pdb file could not be loaded for some reason. When this happens you see a hollow red circle in the left margin of the breakpoint line instead of the full red ball. Could this be your problem?
I have not figured out why this happens sometimes, but in my experience it only happens for breakpoints in modules that are not the main project being debugged. A workaround that I use is to start the debugger from the DLL, putting the exe in the startup debug configuration for the DLL project. Another trick that sometimes helps is to have all the projects in a single solution, and have them all setup with correct references, so that with one compilation you can rebuild the whole thing.
Good luck, I hope this helps.
What's a good way to leverage TDD to drive out thread-safe code? For example, say I have a factory method that utilizes lazy initialization to create only one instance of a class, and return it thereafter:
private TextLineEncoder textLineEncoder;
...
public ProtocolEncoder getEncoder() throws Exception {
if(textLineEncoder == null)
textLineEncoder = new TextLineEncoder();
return textLineEncoder;
}
Now, I want to write a test in good TDD fashion that forces me to make this code thread-safe. Specifically, when two threads call this method at the same time, I don't want to create two instances and discard one. This is easily done, but how can I write a test that makes me do it?
I'm asking this in Java, but the answer should be more broadly applicable.
You could inject a "provider" (a really simple factory) that is responsible for just this line:
textLineEncoder = new TextLineEncoder();
Then your test would inject a really slow implementation of the provider. That way the two threads in the test could more easily collide. You could go as far as have the first thread wait on a Semaphore that would be released by the second thread. Then success of the test would ensure that the waiting thread times out. By giving the first thread a head-start you can make sure that it's waiting before the second one releases.
It's hard, though possible - possibly harder than it's worth. Known solutions involve instrumenting the code under test. The discussion here, "Extreme Programming Challenge Fourteen" is worth sifting through.
In the book Clean Code there are some tips on how to test concurrent code. One tip that has helped me to find concurrency bugs, is running concurrently more tests than the CPU has cores.
In my project, running the tests takes about 2 seconds on my quad core machine. When I want to test the concurrent parts (there are some tests for that), I hold down in IntelliJ IDEA the hotkey for running all tests, until I see in the status bar that 20, 50 or 100 test runs are in execution. I follow in Windows Task Manager the CPU and memory usage, to find out when all the test runs have finished executing (memory usage goes up by 1-2 GB when they all are running and then slowly goes back down).
Then I close one by one all the test run output dialogs, and check that there were no failures. Sometimes there are failed tests or tests which are in deadlock, and then I investigate them until I find the bug and have fixed it. That has helped me to find a couple of nasty concurrency bugs. The most important thing, when facing an exception/deadlock that should not have happened, is always assuming that the code is broken, and investigating the reason ruthlessly and fixing it. There are no cosmic rays which cause programs to crash randomly - bugs in code cause programs to crash.
There are also frameworks such as http://www.alphaworks.ibm.com/tech/contest which use bytecode manipulation to force the code to do more thread switching, thus increasing the probability of making concurrency bugs visible.
When I test drove an implementation that needed to be thread safe recently I came up with the solution I provided as an answer for this question. Hope that helps even though there are no tests there. Hope link is OK raher than duplicating teh answer...
Chapter 12 of Java Concurrency in Practice is called "Testing Concurrent Programs". It documents testing for safety and liveness, but says this is a hard subject. I am not sure this problem is solvable by the tools of that chapter.
Just off the top of my head could you compare the instances returned to see if they are indeed the same instance or if they are different? That's probably where I would start with C#, I would imagine you can do the same in java