Programming Forums - ContextSwitchDeadlock

Programming Forums (http://www.programmingforums.org/forumindex.php)

- Visual Basic .NET (http://www.programmingforums.org/forum19.html)

- - ContextSwitchDeadlock (http://www.programmingforums.org/showthread.php?t=11081)

ContextSwitchDeadlock

Last night I wrote a little application that splits files into individual parts of equal size. The program works greatly efficiently while parting files under 100mb, anything over 100mb and it obviously gets busier, but windows assumes that it is just hanging and results in my application being non responsive.

When it gets round to it, the message I get is 'ContextSwitchDeadlock' error...

http://msdn2.microsoft.com/en-us/library/ms172233.aspx

After looking here, and not really understanding this 100%, im here for help. How could I make my program more efficient, to run quicker with bigger files? Obviously, the bigger the file gets the harder the work, so how can I tell my program to let windows know its busy, and not frozen?

On the msdn page I dont understand this code, is it saying 'Add this code and windows will over look your programs time-taking procedures'? or what?.

any help is greatly appreciated.

it appears as if your thread is not pumping.

Quote:

Failure to Pump

When your STA thread is doing nothing else, it needs to be checking to see if any other threads want to marshal some calls into it. This is done with a Windows message pump. If the STA thread fails to pump, these incoming calls will be blocked. If the incoming calls are GUI SendMessages or PostMessages (which I think of as synchronous or asynchronous calls respectively), then failure to pump will produce an unresponsive UI. If the incoming calls are COM calls, then failure to pump will result in calls timing out or deadlocking.

If processing one incoming call is going to take a while, it may be necessary to break up that processing with intermittent visits to the message pump. Of course, if you pump you are allowing reentrancy to occur at those points. So the developer loses all his wonderful guarantees of single threading.

stolen from: http://blogs.msdn.com/cbrumme/archiv.../02/66219.aspx

are you doing all of this processing on your main thread? I believe the problem is that your application is being too big of a hog. I have no clue what's in your code so....

as the file gets bigger, however you have it implemented, it should not require any more resources than when working with a small file, it should simply take longer and nothing more, you might want to give it its own thread as well while its churning away. so try that and see what happens.

I found 'Application.DoEvents()' helps to carry on pumping messages and using a background worker to automatically organise threads stops the program from hanging, however it is my code that is fundementally flawed.

I meant to bring the code but foolishly left this morning without it.

Before I posted I was using a MemoryStream to copy data and then re-write it, however as this implies memory will get clogged with bigger files, obviously activites using this feature will vary in many aspects from PC to PC, I changed it then to write directly to a FileStream, but to no avail; As for this, it still seems to write all data into memory before writing it to the file, I then posted this thread.

I apologize for the lack of information initilally posted