locked
WinForms racing condition problem - maybe because of progressbar RRS feed

  • Question

  • Description :

    1) Operation is a type that can be run asynchronously. It notifies other objects through it's event named Executed , as follows :
                       
    _Operation.Executed += OperationExecuted;

     

    2) Inside this event, we call the StopProgress() as follows :

    private void OperationExecuted (object sender, OperationEventArgs e)

            {

              StopProgress();

            }

    3) The StopProgress() is as shown below :

    public void StopProgress()

               {

                if (InvokeRequired)

                {

                    Invoke(new MethodInvoker(StopProgress));

                    return;

                }

     

                lblTemp.Text= "operation complete. ";// 1

                //progressBar1.Visible = false; // 2

               }

    ********************************************************

    When commenting line marked "1" (inside StopProgress() ), and uncommenting "2" (which is the desired behavior), we run into racing condition occasionally(after running the app for 5-10 times, we encounter racing conditions). With line "1", it never happens. There is no exceptions thrown(caught/uncaught) either. We are assuming the problem is related to the "ProgressBar" itself.  If not, what could probably be the case here . Any suggestions on how to track down the racing conditions (vulnerable code sections) are also very much appreciated.

    Thanks.

    • Moved by Barry Wang Wednesday, June 26, 2013 5:36 AM
    Monday, June 24, 2013 9:10 AM

All replies

  • Hi justme_pratik,

    I'll move your case to BCL, your case is more related to this forum.

    Regards,


    Barry Wang
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, June 26, 2013 5:37 AM
  • "When commenting line marked "1" (inside StopProgress() ), and uncommenting "2" (which is the desired behavior), we run into racing condition occasionally"

    How do you know that it is a race condition? Where is the code affected by the race condition?

    Wednesday, June 26, 2013 5:53 AM
  • Thanks for your response Mike. I know it's a racing condition because :

    1) the problem do not occur everytime. It occurs randomly, without any pattern whatsoever. Sometimes, it appears in the first run; at others, we have to repeat the process 20-24 times( which ensures that the code has no problems ). 

    2) we don't get any kind of exception(thrown or caught) when the application gets stuck(not hang, as the other background threads(like log thread) continues to do it's job).

    3) while debugging, when in stuck state, if we pause the application, vs shows StopProgress() method. 

    Doesn't all these behaviors point towards racing condition??? If not, what else could it be ??? 


    Pratik Chandra(justme_pratik)

    Wednesday, June 26, 2013 2:08 PM
  • "Doesn't all these behaviors point towards racing condition??? If not, what else could it be ??? "

    Maybe but until you can point exactly where the race condition is this is pure speculation. It seems that the only tangible thing we have right now is the "stuck" behavior and there's nothing obvious in the code that could produce this. And certainly there isn't any race condition in the code you have posted.

    What exactly (current statement, call stack) does the debugger show during pause? If it shows the Invoke method then it's possible that you have a deadlock, not a race condition.

    Do you handle any events (TextChanged, VisibleChanged etc.) from those controls?

    Wednesday, June 26, 2013 2:56 PM
  • No, we don't have any events related to those controls(neither Label nor the ProgressBar). Quite possible that it maybe a deadlock condition. But what would you suggest as the next step for this situation ??? We're out of ideas !!!

    Pratik Chandra(justme_pratik)

    Thursday, June 27, 2013 5:18 AM
  • What about my question: "What exactly (current statement, call stack) does the debugger show during pause?"

    "Quite possible that it maybe a deadlock condition. But what would you suggest as the next step for this situation ??? We're out of ideas !!!"

    Try using BeginInvoke instead of Invoke.

    Thursday, June 27, 2013 5:23 AM
  • Don't know what you call a "racing condition" but you're describing what happens when you invoke a UI method and end the calling thread before the invoke completes.  If BeginInvoke corrects the problem, that's probably the problem.  BeginInvoke may introduce other problems.  Best is to ensure Invoke can complete.
    • Edited by JohnWein Thursday, June 27, 2013 7:06 AM Punctuation
    Thursday, June 27, 2013 7:05 AM
  • When paused, the current line :StopProgress() 

    The call stack is totally the same as it is when the application is not stuck and we've a break point at StopProgress() . We already tried using BeginInvoke in place of Invoke, but to no use.


    Pratik Chandra(justme_pratik)

    Friday, June 28, 2013 4:47 PM
  • but you're describing what happens when you invoke a UI method and end the calling thread before the invoke completes.
    this may very well be the case. But as we've already tried using BeginInvoke, but to no use...what else can be done here ???

    Pratik Chandra(justme_pratik)

    Friday, June 28, 2013 4:50 PM
  • "When paused, the current line: StopProgress()"

    That's probably on the background thread, switch to the main thread and see what it is doing. Try stepping through the code.

    Saturday, June 29, 2013 6:36 AM