ContextSwitchDeadlock

[Guest]

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!!!!

 

[Guest]

OldButStillLearning,
When you opine "can't join these tables - on different machines" are you
saying you can't have a SQL Statement that joins a table on a database in
another server?
You should be able to do this with SQL Server.
It could save you a lot of pain.
Peter

 

[Andy]

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.

 

[Willy Denoyette [MVP]]

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.

in message | 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!!!!
|

 

[Guest]

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.

 

[Willy Denoyette [MVP]]

in message | 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.

 

[Guest]

Thanks Willy, I have no real experience with thread, so I did not answer the
question, because I was not sure how to answer. I did indicate that I had
not created a thread to run this process on, which I was hoping would answer
the question as to if it was being run on a "UI (STA) thread". So If I have
not created a thread, then my assumption was that I was using the "UI (STA)
thread". So is that a good assumption?

As I mentioned, I have no experience in creating or running threads, but I
am looking at an example. Basically, I create a class which has a run method
which does all the processing that I want to have done within the thread, and
I create an instance of that class in my main procedure and then invoke the
run method. Is that about right? But I'm guessing that I need to do
something in the main procedure to "wait" for the "thread to finish" as if I
don't my procedure will terminate the program.

To do this, would I use the Thread.Sleep(XXXXX) within a while loop, which
continues to test if my "thread" is still "alive"? I created the "IsAlive"
propery in my "thread" class, but it will not complile, I get a
"'BatchJobs.SQLThread.IsAlive.get' must declare a body because it is not
marked abstract or extern" when I place this "Property in my thread class
"public bool IsAlive { get; }"

So is this what I should be doing? What am I doing wrong?

Again, Thanks so much for your help!!!!

 

[Willy Denoyette [MVP]]

in message | Thanks Willy, I have no real experience with thread, so I did not answer
the
| question, because I was not sure how to answer. I did indicate that I had
| not created a thread to run this process on, which I was hoping would
answer
| the question as to if it was being run on a "UI (STA) thread". So If I
have
| not created a thread, then my assumption was that I was using the "UI
(STA)
| thread". So is that a good assumption?
|
| As I mentioned, I have no experience in creating or running threads, but I
| am looking at an example. Basically, I create a class which has a run
method
| which does all the processing that I want to have done within the thread,
and
| I create an instance of that class in my main procedure and then invoke
the
| run method. Is that about right? But I'm guessing that I need to do
| something in the main procedure to "wait" for the "thread to finish" as if
I
| don't my procedure will terminate the program.
|
| To do this, would I use the Thread.Sleep(XXXXX) within a while loop, which
| continues to test if my "thread" is still "alive"? I created the
"IsAlive"
| propery in my "thread" class, but it will not complile, I get a
| "'BatchJobs.SQLThread.IsAlive.get' must declare a body because it is not
| marked abstract or extern" when I place this "Property in my thread class
| "public bool IsAlive { get; }"
|
| So is this what I should be doing? What am I doing wrong?
|
| Again, Thanks so much for your help!!!!
|
|

Ok, let me ask whether your application is a windows (Forms) application or
a Console style application.
If it's the former, your main thread is the UI thread and this thread has to
pump the message queue in a regular fashion, if it's the latter, your main
thread is not a UI thread and should not run in an STA, that is, you should
not decorate the Main entry with STAThreaAttribute in order to get rid of
the MDA.
In the case of a windows application, you need to create a thread to run
your Run method. You don't have to wait for the thread procedure to finish,
especially don't call sleep in your UI thread, 'Sleep' blocks the thread for
the duration of the sleep time, something you should never do in an UI
thread.
Let your Run method update the UI when it runs to an end, note however that
you need to marshal the update call to the UI thread by calling
Control.Invoke or Control.BeginInvoke from the Run method.
Please search MSDN for details on the Thread class, Control class and
BackgroundWorker etc...

Willy.

 

[Guest]

My application is a console application.

So I can't tell if the statement "not decorate the Main entry with
STAThreaAttribute in order to get rid of the MDA" means? Is this saying that
I do not need another thread to resolve the issue?

 

[Willy Denoyette [MVP]]

in message | My application is a console application.
|
| So I can't tell if the statement "not decorate the Main entry with
| STAThreaAttribute in order to get rid of the MDA" means? Is this saying
that
| I do not need another thread to resolve the issue?

Ok, we are getting closer, seems like the Oracle provider
(System.Data.OracleClient ?) is using COM interop, question is what are his
threading requirements.

If you have a Main method that has the STAThread attribute, something like
this:

[STAThread]
int Main(...)
..... remove the [STAThread] attribute, and you're done.

If you don't have such attribute, add the attribute like shown above.
Note that when running in a STA, you need to pump messages, that is, you may
not block the pump for too long a period.
To do so, you need to insert a pumping wait calls in your loop. One that
comes to mind is Thread.Join(), so in your loop you simply insert:

while(reader.Read())
{
// process data
// and pump...
System.Threading.Thread.CurrentThread.Join(10);
}
....

This will insert a 'pumping wait' in the current code path for ~10 msecs.
Note however that this all won't work if a single DB command takes more than
the MDA time-out period, if that's the case, all you can do is ignore the
MDA (it should not appear when running outside of VS).

Willy.

 

[Guest]

I am using the Oracle drivers (Oracle.DatabaseAccess) and not the Microsoft
version of the Oracle drivers.
Yes, my "Main" method had the "[STAThread]" and I removed it as you
suggested. I had already modified my program to create a thread for the
process which is reading and looping through the database, and I can not tell
any longer if you believe that is or is not necessary. It almost sound like
you think the removal of the "[STAThread]" is going to do the trick. I have
been wanting to learn more about threading as it is something that I have a
need for in other processes, even if it turns out I do not need it here.

So by taking off the "[STAThread]", the system no longer is checking the
"pump" period? Is that the gist of what is occuring?

My test ran successfully and was not been interupted by the
"ContextSwitchDeadlock" error message, so it would appear that the issue is
resolved, but I'm not sure which action resolved it, changing the process to
run on its' own thread or removing the "[STAThread]", but I suspect that it
was the ""[STAThread]" change.

Again, thanks SOO MUCH FOR YOUR HELP!!!!!!

 

[Willy Denoyette [MVP]]

The STAThread attribute on Main initializes the main thread to enter a
Single Threaded Apartment (STA). STA threads need a message queue to
synchronize it's accesses, if a thread doesn't run a message queue when it
enters the STA, COM will create one on your behalf, but it's up to your code
to pump the messages. Now, without STAThread, the thread remains
uninitialized or enters the MTA and no queue gets created, effectively
removing the requirement for "pumping". That's why you won't see the MDA
again.

Willy.


in message |I am using the Oracle drivers (Oracle.DatabaseAccess) and not the Microsoft
| version of the Oracle drivers.
| Yes, my "Main" method had the "[STAThread]" and I removed it as you
| suggested. I had already modified my program to create a thread for the
| process which is reading and looping through the database, and I can not
tell
| any longer if you believe that is or is not necessary. It almost sound
like
| you think the removal of the "[STAThread]" is going to do the trick. I
have
| been wanting to learn more about threading as it is something that I have
a
| need for in other processes, even if it turns out I do not need it here.
|
| So by taking off the "[STAThread]", the system no longer is checking the
| "pump" period? Is that the gist of what is occuring?
|
| My test ran successfully and was not been interupted by the
| "ContextSwitchDeadlock" error message, so it would appear that the issue
is
| resolved, but I'm not sure which action resolved it, changing the process
to
| run on its' own thread or removing the "[STAThread]", but I suspect that
it
| was the ""[STAThread]" change.
|
| Again, thanks SOO MUCH FOR YOUR HELP!!!!!!
|

 

[Guest]

OK, I thought the IDE generated the "STAThread" when it created the class for
me, but maybe not, because I have done a lot of maintenance on it and perhaps
I copied something from another class. I can't say for sure.

So what is a message que and when do I need one, as I apparently do not need
one in this instance.....

 

[Andy]

The message queue (I believe) is how windows tells your application
which events are raised. So your application may get a messge asking
it to refresh, handle a user click event, etc. While you are working
in the main thread, your UI can't respond to those events until your
code completes. Build a windows forms application, and add a button to
a form. IN the button click handler, add a
System.Threading.Thread.CurrentThread.Sleep( 10000 ) call. Then try to
move the form or drag another window over it, and notice it doesn't
repaint. Eventually the thread will 'wake up' and handle the events
(Paint, Move, etc). Unless you explicitly create another thread,
you're always working on the main thread.

Sounds like using the STAThread attribute will automatically create a
message queue (aka message pump) on the main thread.

Working with threads is fairly easy, but can also be easy to mess up.
If you're doing a Windows form application you probably will want to
use the BackgroundWorkerProcess component. It will handle a background
thread so that your UI can continue to update smoothly. It works by
creating an event handler for the components DoWork event. The code in
here is the code that will actually execute on a background thread. In
the DoWork event handler, you can raise another event to report
progress back to your ui. The UI will remain responsive instead of
blocking using this component.