locked
the while loop stops asynchronous operation in other thread RRS feed

  • Question

  • I have a device connected thru USB port. This is an asynchronous communication and it is triggered by running timer. The form is updated via delegate. I want to have a "while" loop that evaluates one of the parameters received from USB.
    However, it works correctly only from time to time. Most of the time it's stock in the while loop. The code is to complex to be listed here so I just post the sample of the while loop. It appears that the timer operation stops but then when I click on some controls on the form it resumes operation exiting the while loop. That would mean the parameter was evaluated successfully at that point.

    while ( usbparametertobeevaluated)
    {
    Application.DoEvents();
    }

    I run timer with many different parameters from 10ms to 500ms and it doesn't appear to have any significant effect.

    I just want to suspend one thread while waiting for received parameter to be true.
    Is there any clean way to implement this?

    Sunday, March 3, 2013 11:42 PM

Answers

  • I fixed it with a different timer.

    Now, I use

    System.Windows.Forms.Timer
    and it's Tick event

    It looks like this timer was designed to run in Forms.

    Thank you all for suggestions.

    • Marked as answer by mikeocean Sunday, April 14, 2013 10:08 PM
    Sunday, April 14, 2013 10:05 PM

All replies

  • The question is wich timer you use. There are at least 3 of them. Some of the run forcibly on the UI thread:
    http://msdn.microsoft.com/en-us/magazine/cc164015.aspx

    Also check if there is any part in your Thread code that upadtes the UI. For example, my first attempts at seperate THreading using Backgroudn Worker did this on completion:

    int[] listOfPrims; //result from Async operation
    
    foreach(int Prim in listOfPrims)
      textBox1.Text += Prim;

    While thsi code did work well with small amounts of prims (say everyone below 100) it could seem to totalyl crash/hang with llarge numbers (all below 65536). The problem was that I:

    a) used String Conaction, where I should have used a String builder
    b) repeatedly set the Property of a UI Control, wich caused UI updates to be fired.


    Let's talk about MVVM: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b1a8bf14-4acd-4d77-9df8-bdb95b02dbe2


    Monday, March 4, 2013 2:04 AM
  • my timer is defines as follows

    public static System.Timers.Timer tmrContinuousDataCollect; 

    and then

    tmrContinuousDataCollect = new System.Timers.Timer(50);
    tmrContinuousDataCollect.Elapsed += new ElapsedEventHandler(OnDataCollect);
    tmrContinuousDataCollect.Stop();
    tmrContinuousDataCollect.SynchronizingObject = this;

    Monday, March 4, 2013 2:17 AM
  • Hi mikeocean,

    Can you post the actual code? What "type" of asynchronous programming are you doing? That is, are you using ThreadPool, BackgroundWorker, Await/Async, etc? It seems you may find it easier to use a TimerCallback. As stated in the doc:

    "Use a TimerCallback delegate to specify the method that is called by a Timer. This method does not execute in the thread that created the timer; it executes in a separate thread pool thread that is provided by the system. The TimerCallback delegate invokes the method once after the start time elapses, and continues to invoke it once per timer interval until the Dispose method is called, or until the Timer.Change method is called with the interval value Infinite."

    Monday, March 4, 2013 2:30 AM
  • "Use a TimerCallback delegate to specify the method that is called by a Timer. This method does not execute in the thread that created the timer; it executes in a separate thread pool thread that is provided by the system. The TimerCallback delegate invokes the method once after the start time elapses, and continues to invoke it once per timer interval until the Dispose method is called, or until the Timer.Change method is called with the interval value Infinite."

    But: You can set a property called SynchronizingObject. If you add the Timer to a Form/Window using desinger, it will likely be set to run on the Form/Window.
    Setting this property to the UI means that the Tick event is executed on the UI Thread. If the UI thread is busy, the Tick events can't be executed but will still be queued normal (like a Click event would be).

    Also, jsut an idea: Are you certain the UI is informed that it should redraw after each Timer Tick? Depending on what you set the Ui might not now it has to redraw now. And your Click only "seems" to solve this, by Forcing a redraw.


    Let's talk about MVVM: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b1a8bf14-4acd-4d77-9df8-bdb95b02dbe2

    Monday, March 4, 2013 5:25 PM
  • Agreed, we need some code to determine what is really going on. With that said, I would still rather use the TimerCallback delegate :)
    Monday, March 4, 2013 6:26 PM
  • Thank you all for the tips.

    I followed TimerCallback example from MSDN http://msdn.microsoft.com/en-us/library/system.threading.timercallback.aspx

    ...actually I just copied the code directly to testbutton_click.
    However, once it runs it will suspend all activity on my form until it finishes. The example outputs to Console.

    I would copy here some of my code but I don't know where to start. At this moment I have about >20k lines of code and clearly I'm getting lost in what is doing what.

    Tuesday, March 5, 2013 3:00 PM
  • Yes, UI redraws after each Timer tick and it works fine approx 25% of the time, but 75% of the time it waits in the "while loop". Then, when I click on any control in the form it exits the "while loop". Actually I have to click twice...first click may be on any area of the form then second on the control
    Tuesday, March 5, 2013 3:09 PM
  • The issue is that we need a ready-to-compile example of your Problem. Otherwise we cannot even verrify if it is a computer issue (instead of Programming issue).

    Right now oyu asume the while loop & some specific part of code do not interact well. So make a new project, add the Callback, add the while loop and see what happens. If happens what you expect, then post that short code.

    When you don't understand what is happening, we have no chance of understanding it either much less debug anything.


    Let's talk about MVVM: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b1a8bf14-4acd-4d77-9df8-bdb95b02dbe2

    • Marked as answer by Bob Shen Monday, March 11, 2013 11:40 AM
    • Unmarked as answer by mikeocean Sunday, April 14, 2013 10:06 PM
    Tuesday, March 5, 2013 4:35 PM
  • I will try to follow your advice and test it on new and smaller project. thanks
    Tuesday, March 5, 2013 6:34 PM
  • I fixed it with a different timer.

    Now, I use

    System.Windows.Forms.Timer
    and it's Tick event

    It looks like this timer was designed to run in Forms.

    Thank you all for suggestions.

    • Marked as answer by mikeocean Sunday, April 14, 2013 10:08 PM
    Sunday, April 14, 2013 10:05 PM
  • There are at least 3 different Timer classes in .NET, each of them varriers about in wich thread the timer runs.

    And to make it worst, there is no "best" Timer:

    http://msdn.microsoft.com/en-us/magazine/cc164015.aspx


    Let's talk about MVVM: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b1a8bf14-4acd-4d77-9df8-bdb95b02dbe2

    Monday, April 15, 2013 9:01 AM