ContextSwitchDeadlock
in [CSharp]
|
From: OldButStillLearning on 26 Apr 2006 16:23 Hello, I am getting this "ContextSwitchDeadlock" error message pop up in situations where I am doing a Data Reader loop, where I am processing about 40,000 records. For each record read via the data reader, I am creating another data reader to read another database table (can't join these tables - on different machines) to get additional information. I am guessing that I am getting this error message becuase the loop is taking longer the 60 seconds to complete. Here is what is said about the error "The most probable cause is that a single-threaded apartment (STA) thread is not pumping messages. The STA thread is either waiting without pumping messages or is performing lengthy operations and is not allowing the message queue to pump." I'm sorry, but I do not have a clue as to what this means. The other probable cause is a process is consuming too much memory. Not sure That this would apply to me but perhaps opening and closing 40,000 data readers is sucking up memory, although I would have expected the garbage collector to have released this memory, but perhpas because it is all within the same paragraph, the memory is not being release. I often just cancel out of the error message and continue with the process and it completes successfully, so I don't think it is a memory issue. If I do not run in debug mode, I get the same error message running in "Release" mode. I read that you can turn off the MDA errors via the config file, but this does not seem to me to be the appropriate solution to the problem... Does it? Any ideas or suggestions? Thanks in advance for your assistance!!!!
From: Andy on 26 Apr 2006 16:52 First, I'm assuming you hve a UI running? If you can't do as Peter suggests, you may want to try running this process in its own thread.
From: Willy Denoyette [MVP] on 26 Apr 2006 17:17 If you run this on a UI thread, you should move this task to an auxiliary thread, the task blocks the pump for too long (that's why you see the MDA in debug mode). If it's not a UI thread, you should not initialize the thread as an STA thread. Willy. "OldButStillLearning" <OldButStillLearning(a)discussions.microsoft.com> wrote in message news:28E614A8-82D3-43D9-AD90-5B3FC8718267(a)microsoft.com... | Hello, I am getting this "ContextSwitchDeadlock" error message pop up in | situations where I am doing a Data Reader loop, where I am processing about | 40,000 records. For each record read via the data reader, I am creating | another data reader to read another database table (can't join these tables - | on different machines) to get additional information. I am guessing that I | am getting this error message becuase the loop is taking longer the 60 | seconds to complete. Here is what is said about the error | "The most probable cause is that a single-threaded apartment (STA) thread is | not pumping messages. The STA thread is either waiting without pumping | messages or is performing lengthy operations and is not allowing the message | queue to pump." | | I'm sorry, but I do not have a clue as to what this means. The other | probable cause is a process is consuming too much memory. Not sure That this | would apply to me but perhaps opening and closing 40,000 data readers is | sucking up memory, although I would have expected the garbage collector to | have released this memory, but perhpas because it is all within the same | paragraph, the memory is not being release. I often just cancel out of the | error message and continue with the process and it completes successfully, so | I don't think it is a memory issue. | If I do not run in debug mode, I get the same error message running in | "Release" mode. | | I read that you can turn off the MDA errors via the config file, but this | does not seem to me to be the appropriate solution to the problem... Does it? | | Any ideas or suggestions? | | Thanks in advance for your assistance!!!! |
From: OldButStillLearning on 27 Apr 2006 09:21 The tables being accessed are Oracle, and while I could interject SQL Server into the equation, I think this overly complicates things and I'm not exactly sure why I would not run into the same issue. I am not creating a seperate thread for this processing, but if I do this, I'm still not quite sure how this aleviates the problem? Why would placing this process in its' own thread now eliminate the error message that the process is taking longer the 60 seconds? Even if I place the process in another thread, it will still take longer then 60 seconds, so how does this solve the problem? If I resorted to introducing SQL Server and called a stored procedure which invoked a DTS package, that process would, as well, take longer then 60 seconds, so how would interjecting SQL server help resolve the problem either? Thanks in advance for your assistance.
From: Willy Denoyette [MVP] on 27 Apr 2006 10:06 "OldButStillLearning" <OldButStillLearning(a)discussions.microsoft.com> wrote in message news:013119B9-6434-4D14-8BDD-EB823FA9C6C4(a)microsoft.com... | The tables being accessed are Oracle, and while I could interject SQL Server | into the equation, I think this overly complicates things and I'm not exactly | sure why I would not run into the same issue. | | I am not creating a seperate thread for this processing, but if I do this, | I'm still not quite sure how this aleviates the problem? Why would placing | this process in its' own thread now eliminate the error message that the | process is taking longer the 60 seconds? Even if I place the process in | another thread, it will still take longer then 60 seconds, so how does this | solve the problem? | | If I resorted to introducing SQL Server and called a stored procedure which | invoked a DTS package, that process would, as well, take longer then 60 | seconds, so how would interjecting SQL server help resolve the problem either? | | Thanks in advance for your assistance. | Well, actually you didn't answer the question why you run this on an UI (STA) thread, but I assume it's the case. The UI (STA) thread has a message queue that needs to get 'pumped' in a timely fashion, the CLR (in debug mode only) will inject a ContextSwitchDeadlock" exception when you fail to pump once per 60 secs. So, if you want to: - get rid of this MDA and, - if you want your UI thread to stay responsive (which is not the case if you block the pump), and optionally - if you don't want to take the risk to block the finalizer thread in COM scenarios. you will have to move the task to another thread which doesn't have a message queue, that is to a non UI non STA thread. Willy.
|
Next
|
Last
Pages: 1 2 3 Prev: WebBrowser class Next: Setting value for unbound DataGridViewComboBoxCell |