With parallel processing be it background or task in debug will jump around. I end up adding a break point at every line. Is there a way to only step in the task and just put a single break point at the beginning?
While paused in the debugger, you can use the Threads window to have more control over context switching. You can right click on a Thread and select Freeze. This will prevent the debugger from switching to that thread while you're stepping through code. You can also Shift-Select multiple threads and Freeze them all. If you Freeze all threads other than the thread you're stepping though, you can step through unhindered by other processing.
It's a bit awkward, but you can also use this to investigate some types of race conditions by explicitly Thawing only one thread and then forcing the active thread to change (using Switch to Thread) at the specific point you want to test. This won't replicate all types of threading synchronization issues (some are much more subtle, dealing with memory caching on separate CPUs and the like), but you can see the effects of alternate execution orders (such as some deadlock scenarios.)
Related
I'm working on about 35 batches updating many databases as a part of our daily process at work. Every batch of them was developed in a single web app. Due to database issues, i have collected all of them in one windows application to make use of DB connection pooling and i have assigned a single backgroundworker for each batch. Reaching to 20 batch in the application, every thing is working good. But when i add any other backgroundworker for any other batch, the application hangs.I think this is because i'm running too many threads in one process. Is there a solution for this problem, for example, making the application working with many processes ??!!!.
Regards,
Note,
I have assigned a single machine for this application (Core i7 cpu, 8 gb ram).
How many databases you have to update?
I think it is more recommended to have the number of Threads as the number of Databases
If your UI is freezing while many background workers are active, but recovers when those background workers are finished processing, then likely the UI thread is executing a method which waits for a result or signal from one of the background worker threads.
To fix your problem, you will have to look for UI-related code that deals with synchronization / multi-threading. This might be places where one of the many synchronization objects of .NET are being used (including the lock statement), but it could also involve "dumb" polling loops a-ka while(!worker.IsFinished) Thread.Sleep();.
Another possible reason for the freeze might be that you are running a worker (or worker-related method) accidentally in the UI thread instead in a background thread.
But you will find out when you use the debugger.
To keep the scope of your hunt for problematic methods managable, let your program run in the debugger until the UI freezes. At that moment, pause the program execution in the debugger. Look which code the UI thread is processing then, and you will have found one instance of offending code. (Whatever there is wrong, i can't tell you - because i don't know your code.)
It is quite possible that different UI-related methods in your code will suffer from the same issue. So, if you found the offending code (and were able to fix it) you would want to check on for other problematic methods, but that should be rather easy since at that point of time you will know what to look for...
Currently I have a background thread that does some periodic heavy data management. Because it only needs to run its process every few hundred milliseconds I call Thread.Sleep() at the end of the process and it then goes back to the top of the loop and repeats.
This is all working perfectly and doesn't cause any grief or performance issues for the rest of the software. The only thing that does bug me though is that when I break the debugger instead of going to my main threads current location, it gets stolen by the Thread.Sleep() and takes me there instead.
Is there any way that I can disable the debugger from stopping on that line, or is there an alternative to putting the Thread to sleep?
Thanks in advance!
One thing you could try is to put the Thread.Sleep() in a method and add the DebuggerStepThrough on it.
You can also just "freeze" the you don't want to "steal focus" from Threads window (Debug -> Windows -> Threads). Also remember to unfreeze them when you're done
As an aside using a Timer (there are two) or a AutoReset Event is preferred to using Thread.Sleep() See Is Sleep() evil?
As everybody, I am used to debugging my code in VS in step-by-step mode. Well, now that I have an application with many Background Workers everywhere, I am not in Kansas anymore.
What is the most efficient way to debug threaded applications and be able to monitor each and every thread to keep track of what's happening all over the code?
As of now, I stick to good ol' debugging using separate logger instances for each Thread, but this is slowly becoming a nightmare and I'll soon be drowning into my own logs.
Don't try to debug everything all at once. Narrow your focus to a particular behavior in one thread or pair of threads that interact around some mutex lock. If accessing a shared resource is the problem, set breakpoints around use of that resource (which should be in common code, not all over the place).
If you just want to see that thread 3 completed before thread 1, or that thread 2 used up all its work items and is sitting idle, use logs for that.
You can also use the VS Threads view to see what each thread is doing whenever the process is stopped at any breakpoint on any thread. This can give you some insight into what all the threads are doing at any given instant.
A small tip that might ease your pain is to use Visual Studio to freeze threads that you are not interested in. Then when you tell the debugger to continue, the frozen threads will never execute and will not hit breakpoints and confuse you.
Maybe you can use this method to allow only the threads you are debugging to work. E.g. keep one thread that enqueues and one thread that dequeues active, but freeze everything else.
You can freeze/thaw threads from Visual Studio's Threads window, by right-clicking on a thread.
Write it correctly the first time.
Joking aside, the trick to debugging is to break it down into manageable parts. Tackle one worker task at a time, make absolutely sure it does what it's supposed to.
Once you've done that, debugging issues in the main thread is a lot easier, because you can pretty much ignore the background workers and just presume they're yielding correct results when they should be.
The only place left that's harder to debug than a single-threaded application is the interconnect between the threads, which shouldn't be much more difficult if you're using the libraries the way you should be.
I Stumbled upon a detailed MSDN article about Debugging Multithreaded Applications
wich was of great help. Thanx for all the previous answers that guided me towards the right track.
Is it possible to break a single thread in Visual Studio, while other threads will continue their execution?
I have one background thread that does simple data sending/receiving, which I would like to happen, while stepping through my code in some other thread.
open the thread view (Debug->Windows->Threads), right-click the thread you want to suspend, select 'Freeze'. Select 'Thaw' to put it back in a running state.
Generally it's impossible, but there are some things that might work for specific scenarios.
Basic solution
As mentioned elsewhere, repeating the sequence: Freeze, Resume, (wait), Pause, Thaw, Step should result in the behavior you describe, giving other threads the possibility of running in the background while your target thread is halted.
This approach has at least two issues:
It's quite tedious
Your background threads will be suspended anytime the debugger is paused.
Improvements
The first issue may be tackled using a different procedure: Issue a Thread.Sleep(10000) in the Immediate Window, effectively keeping the focused thread occupied while the other threads execute normally. You could even bind that command to a macro.
The second issue can only be tackled by an approach that does not need to pause the debugger. But how would we examine state when the session isn't paused? That's where IntelliTrace comes in, but you may find you need to create custom IntelliTrace events. Drawback of this approach is that you can not manually modify state mid-flight.
Set a counter that does a one up for each thread created and then set your break point to break on a condition and pick a value for that counter. I don't think this will work in all cases, especially PLINQ, but should be doable in a lot of situations.
All i can find to this, is that you can change the behaviour on a process level by the setting
Tools - Options - Debugging - General - Break all processes when one process breaks
but not on a Thread base.
You can always put a conditional break point based on a property of your current thread (like the name or id).
You may also find this usefull : http://www.codeproject.com/Tips/396617/Conditional-Breakpoint-using-Make-Object-Id-featur
This worked for me in VS2008 and should work in a similar way in 2010 at the least
Scenario
I have a Windows Forms Application. Inside the main form there is a loop that iterates around 3000 times, Creating a new instance of a class on a new thread to perform some calculations. Bearing in mind that this setup uses a Thread Pool, the UI does stay responsive when there are only around 100 iterations of this loop (100 Assets to process). But as soon as this number begins to increase heavily, the UI locks up into eggtimer mode and the thus the log that is writing out to the listbox on the form becomes unreadable.
Question
Am I right in thinking that the best way around this is to use a Background Worker?
And is the UI locking up because even though I'm using lots of different threads (for speed), the UI itself is not on its own separate thread?
Suggested Implementations greatly appreciated.
EDIT!!
So lets say that instead of just firing off and queuing up 3000 assets to process, I decide to do them in batches of 100. How would I go about doing this efficiently? I made an attempt earlier at adding "Thread.Sleep(5000);" after every batch of 100 were fired off, but the whole thing seemed to crap out....
If you are creating 3000 separate threads, you are pushing a documented limitation of the ThreadPool class:
If an application is subject to bursts
of activity in which large numbers of
thread pool tasks are queued, use the
SetMinThreads method to increase the
minimum number of idle threads.
Otherwise, the built-in delay in
creating new idle threads could cause
a bottleneck.
See that MSDN topic for suggestions to configure the thread pool for your situation.
If your work is CPU intensive, having that many separate threads will cause more overhead than it's worth. However, if it's very IO intensive, having a large number of threads may help things somewhat.
.NET 4 introduces outstanding support for parallel programming. If that is an option for you, I suggest you have a look at that.
More threads does not equal top speed. In fact too many threads equals less speed. If your task is simply CPU related you should only be using as many threads as you have cores otherwise you're wasting resources.
With 3,000 iterations and your form thread attempting to create a thread each time what's probably happening is you are maxing out the thread pool and the form is hanging because it needs to wait for a prior thread to complete before it can allocate a new one.
Apparently ThreadPool doesn't work this way. I have never checked it with threads before so I am not sure. Another possibility is that the tasks begin flooding the UI thread with invocations at which point it will give up on the GUI.
It's difficult to tell without seeing code - but, based on what you're describing, there is one suspect.
You mentioned that you have this running on the ThreadPool now. Switching to a BackgroundWorker won't change anything, dramatically, since it also uses the ThreadPool to execute. (BackgroundWorker just simplifies the invoke calls...)
That being said, I suspect the problem is your notifications back to the UI thread for your ListBox. If you're invoking too frequently, your UI may become unresponsive while it tries to "catch up". This can happen if you're feeding too much status info back to the UI thread via Control.Invoke.
Otherwise, make sure that ALL of your work is being done on the ThreadPool, and you're not blocking on the UI thread, and it should work.
If every thread logs something to your ui, every written log line must invoke the main thread. Better to cache the log-output and update the gui only every 100 iterations or something like that.
Since I haven't seen your code so this is just a lot of conjecture with some highly hopefully educated guessing.
All a threadpool does is queue up your requests and then fire new threads off as others complete their work. Now 3000 threads doesn't sounds like a lot but if there's a ton of processing going on you could be destroying your CPU.
I'm not convinced a background worker would help out since you will end up re-creating a manager to handle all the pooling the threadpool gives you. I think more you issue is you've got too much data chunking going on. I think a good place to start would be to throttle the amount of threads you start and maintain. The threadpool manager easily allows you to do this. Find a balance that allows you to process data while still keeping the UI responsive.