Wrox Programmer Forums
Go Back   Wrox Programmer Forums > C# and C > C# 2008 > C# 2008 aka C# 3.0
| Search | Today's Posts | Mark Forums Read
C# 2008 aka C# 3.0 Discuss the Visual C# 2008 (aka C# 3.0) language
Welcome to the p2p.wrox.com Forums.

You are currently viewing the C# 2008 aka C# 3.0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
  #1 (permalink)  
Old May 3rd, 2008, 06:11 AM
Authorized User
Join Date: Apr 2008
Location: , , .
Posts: 13
Thanks: 0
Thanked 0 Times in 0 Posts
Default SwitchDeadlockMDA ??? !! ?

Hello Sam (or anyone)

Okay, this one looks like a real stinker. (I am a poor but honest C programmer getting to grips with the gorgeous -- but pretty picky -- Visual C# programming environment.)

I am used to prolonged attempts at debugging which include swearing at the screen, etc etc. But this one I have no idea how to begin handling:

My program (see last thread) performs an enormous number of pretty simple calculations using three parameters (it was five, but I cut the number down to make life easier.)

In other words, it takes the loose form:

for (x = 0; x < 100; x++)
    for (y = 0; y <100; y++)
        for(z = 0; z <100; z++)
           (do sequence of simple calculations) . . .

This loop repeatedly crashes, for no apparent reason, except that it produces a window with a message muttering on about Context Switch Deadlocks and something called MDA.

I tended, until a couple of days ago, not to examine this message deeply since it meant nothing whatever to me. Until I noticed something about "if 60 seconds have passed without pumping . . . ."

Now: I discover, after much use of hand-made debugging statements, that if my multiple loop takes more than about a minute to execute, this window is indeed produced.

If I increase the 'step' to say "x (or Y or z) += 10", though, so that the entire loop executes inside a minute, all is well.

Okay, no fooling, sixty-odd seconds without anything happening on screen --- that is, with just the Form present but no messages or other visible occurrences being produced --- triggers the (M)anaged (D)ebugging (A)ssistant [suggested substitute acronyms spring readily to mind) into preventing my program from producing a result.

Fine. I can see it's trying to be helpful and does at least save me from sitting there in an endless loop, but I know the loop isn't in fact endless because increasing the aforementioned 'for/next step size' lets it end quite nicely, as long as it does so inside minute.

I cannot however use a step value of anything larger than 1, as it happens, and am quite prepared to sit and drink coffee for the ten or fifteen minutes it may actually take to execute with this small step size even with my superduperfast Cray-type processor (ok, Athlon or whatever). So:

How do I --

-- disable the MDA? or

-- make the application do some 'pumping', whatever 'pumping' may be?

-- or otherwise handle this problem?

With cheers and love,

Martin Woodhouse.

  #2 (permalink)  
Old May 3rd, 2008, 12:28 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts


I think the problem here is that you've got this very busy activity happening on the UI thread. When you get into this loop the UI thread becomes bogged down and is unresponsive to the typical message pumping that drives the form.

Your best bet is to utilize a background worker instance on which you run this calculation process. Once you start this calculation on the background thread that may very well take many minutes to complete processing the call on the UI thread that starts it (button click, or whatever) will return immediately, letting the message pumping continue and eliminating the problem of the MDA thinking that something is wrong. Your UI can still respond to user events, but the calculation will be happily running in the background. Doing this would also give you the opportunity to provide progress feedback of your calculation loops. the BackgroundWorker class provides a method for passing progress back to the UI without you needing to deal with the cross thread invocation that you typically have to implement manually in multi threaded applications.


Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.