Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor
  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. C#
  4. thread is blocking the gui form, why?

thread is blocking the gui form, why?

Scheduled Pinned Locked Moved C#
csharphelpquestionc++
15 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Luc Pattyn

    Hi, it seems like you have a thread with a priority above normal (hence above the UI thread) and with a "busy loop" (while !quitthread GetImage). It is not apparent from the code shown that this loop ever relinquishes the CPU; if it does not, there is a design error (not a language issue) and I would suggest you add a Thread.Sleep(100) somewhere, possibly in the else of your newimg test. Hope this helps. :)

    Luc Pattyn [My Articles]

    K Offline
    K Offline
    Krzysztof Gorgolewski
    wrote on last edited by
    #6

    hi luc, yes correct, but also if i'm not using the priority above normal, it's showing the busy gui. and on my side it's not safe to use a sleep in this infinite loop, because i'm waiting for trigger signals from the device and using the sleep could miss some signals. i mean, i tried exactly the same in c++ without any sleep, with and without higher priority and it's working nicely. so what's the difference between c++'s and .net's threading? criss

    L G 2 Replies Last reply
    0
    • M Martin 0

      Hello, I think you also have to invoke the display method, as you are getting the image instance from an other thread! All the best, Martin

      K Offline
      K Offline
      Krzysztof Gorgolewski
      wrote on last edited by
      #7

      hi martin, worth to try, but i don't think so... the image is displayed correctly. just the "taking image" method causes the problem, it's waiting the whole "timeout" time for a signal (trigger) and if any occurs, then the image is coming. because of the waiting (and blocking the gui) i'm forced to use a thread. :| criss

      M 1 Reply Last reply
      0
      • K Krzysztof Gorgolewski

        hi luc, yes correct, but also if i'm not using the priority above normal, it's showing the busy gui. and on my side it's not safe to use a sleep in this infinite loop, because i'm waiting for trigger signals from the device and using the sleep could miss some signals. i mean, i tried exactly the same in c++ without any sleep, with and without higher priority and it's working nicely. so what's the difference between c++'s and .net's threading? criss

        L Offline
        L Offline
        Luc Pattyn
        wrote on last edited by
        #8

        Hi Criss, I know of no major difference between the threading model available in .NET and the one in C++; they both are built on top of the Windows kernel capabilities. The scheduler's behavior varies from one Windows version to the next; the theoretical "highest ready process gets all, highest ready thread gets all" is not followed, Microsoft has decided long time ago to reserve some CPU cycles to the lower-priority ready processes/threads (but not enough to keep your UI really responsive !). Nevertheless it is a bad idea to have a busy thread, i.e. a thread that loops without explicitly relinquishing the CPU (as with a Thread.Sleep or some semaphore wait or something). So if you claim you have two implementations (C# and C++) that, running on the same machine, behave quite differently, I am puzzled, that is the only explanation I can offer is you have a bug somewhere. I am worried about your "not missing some signals": you cannot prevent a Windows PC from focusing on something else (networking, floppy/CD access, whatever). To be safe, you should have full handshake (in my opinion that means the "4 arrow" model) for all events you want to be sure to see. The only real alternative is to have a real-time thread, which definitely is not supposed to execute infinite loops... BTW: what is the hardware interface and the comm protocol you are using ? and what is the OS, and the .NET version ? :)

        Luc Pattyn [My Articles]

        1 Reply Last reply
        0
        • K Krzysztof Gorgolewski

          hi luc, yes correct, but also if i'm not using the priority above normal, it's showing the busy gui. and on my side it's not safe to use a sleep in this infinite loop, because i'm waiting for trigger signals from the device and using the sleep could miss some signals. i mean, i tried exactly the same in c++ without any sleep, with and without higher priority and it's working nicely. so what's the difference between c++'s and .net's threading? criss

          G Offline
          G Offline
          Guffa
          wrote on last edited by
          #9

          Krzysztof Gorgolewski wrote:

          and on my side it's not safe to use a sleep in this infinite loop, because i'm waiting for trigger signals from the device and using the sleep could miss some signals.

          If the code would be so time critical, then it would not be possible to maintain a GUI at all while it's running, as the thread does not get any CPU cycles while the GUI is being updated. Try to put a Thread.Sleep(0) in the loop to allow any CPU time at all to go to the GUI thread.

          --- single minded; short sighted; long gone;

          K 1 Reply Last reply
          0
          • K Krzysztof Gorgolewski

            hi martin, worth to try, but i don't think so... the image is displayed correctly. just the "taking image" method causes the problem, it's waiting the whole "timeout" time for a signal (trigger) and if any occurs, then the image is coming. because of the waiting (and blocking the gui) i'm forced to use a thread. :| criss

            M Offline
            M Offline
            Martin 0
            wrote on last edited by
            #10

            Hello, Yes I know that this is not going to solfe your problem. I just think if your thread is finished (and you display this image which you are getting from the thread) you will see the original image before you started the thread. For your problem: Mabe a Application.DoEvents() helps you. All the best, Martin

            1 Reply Last reply
            0
            • G Guffa

              Krzysztof Gorgolewski wrote:

              and on my side it's not safe to use a sleep in this infinite loop, because i'm waiting for trigger signals from the device and using the sleep could miss some signals.

              If the code would be so time critical, then it would not be possible to maintain a GUI at all while it's running, as the thread does not get any CPU cycles while the GUI is being updated. Try to put a Thread.Sleep(0) in the loop to allow any CPU time at all to go to the GUI thread.

              --- single minded; short sighted; long gone;

              K Offline
              K Offline
              Krzysztof Gorgolewski
              wrote on last edited by
              #11

              the blocking method is the "taking image" (GetImage) method. it's waiting till a signal is triggering the device DIRECTLY. for the device i can setup a "timeout" which i have to set to some seconds. so my problem is not the entire infinite busy loop, it's the GetImage method, which is not returning until it gets a trigger or a timeout occurs. because of this i put it in a seperate thread, to get the gui not blocked. i'm also confused :| btw: i'm using: winxp + .net 2 + usb connected camera device criss -- modified at 5:41 Monday 16th April, 2007

              G 1 Reply Last reply
              0
              • K Krzysztof Gorgolewski

                hi christian, in the forms constructor i'm having the following lines of code earlier listed, which should start my camerathread (the another/seperate thread) or am i wrong? and if this is not doing what i'm thinking it should do, how should it be?

                ct = new camerathread();
                ct.newimg += new newimg_handler(ct_newimg);
                camerawork = new System.Threading.Thread(new System.Threading.ThreadStart(ct.run));
                camerawork.Priority = System.Threading.ThreadPriority.AboveNormal;
                camerawork.Start();

                criss

                C Offline
                C Offline
                Christian Graus
                wrote on last edited by
                #12

                OK, yes, that should work.

                Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )

                1 Reply Last reply
                0
                • K Krzysztof Gorgolewski

                  the blocking method is the "taking image" (GetImage) method. it's waiting till a signal is triggering the device DIRECTLY. for the device i can setup a "timeout" which i have to set to some seconds. so my problem is not the entire infinite busy loop, it's the GetImage method, which is not returning until it gets a trigger or a timeout occurs. because of this i put it in a seperate thread, to get the gui not blocked. i'm also confused :| btw: i'm using: winxp + .net 2 + usb connected camera device criss -- modified at 5:41 Monday 16th April, 2007

                  G Offline
                  G Offline
                  Guffa
                  wrote on last edited by
                  #13

                  Then it depends on how the GetImage is implemented. If it doesn't allow other threads to run while it's waiting, it won't make any difference that it runs in a different thread than the GUI. If I understand it correctly, the process scheduler can fully handle the time sharing between applications, but it depends on all the threads in an application to cooperate for the time sharing to work between the threads within the application.

                  --- single minded; short sighted; long gone;

                  K 1 Reply Last reply
                  0
                  • G Guffa

                    Then it depends on how the GetImage is implemented. If it doesn't allow other threads to run while it's waiting, it won't make any difference that it runs in a different thread than the GUI. If I understand it correctly, the process scheduler can fully handle the time sharing between applications, but it depends on all the threads in an application to cooperate for the time sharing to work between the threads within the application.

                    --- single minded; short sighted; long gone;

                    K Offline
                    K Offline
                    Krzysztof Gorgolewski
                    wrote on last edited by
                    #14

                    hm... i see, so that means, there is a difference between the implementation for c++ and c#.net (which is an activex control) for this method/class. i think, i should directly contact the support for the device because it's not more looking as a .net problem, more like the implementation... thanks guffa criss

                    1 Reply Last reply
                    0
                    • K Krzysztof Gorgolewski

                      hi, i'm having a silly problem and i'm trying to describe it as simple as possible :) i'm accessing a device which takes images. this device has a timeout property, which i have to set high (for some seconds). if a timeout occurs, it is "catched". after an image is taken, it is shown in my gui window. so, i put the device accessing part in a thread which is getting the images and sending the images to the gui. in code it looks like this:

                      public delegate void newimg_handler(object sender, newimage_args e);

                      public class camerathread
                      {
                      public event newimg_handler newimg;

                      bool quitthread;

imageobject img;

public camerathread()
{
	img = new imageobject();
	quitthread = false;

	OpenImageDevice();

}

public void exithread()
{
	quitthread = true;
}

public void run()
{
	while (!quitthread)
	{
		try
		{
			GetImage(out img);
			if(newimg != null)
			{
				newimage\_args nia = new newimage\_args();
					nia.img = img;
					newimg(this, nia);
			}
		}
		catch
		{
		}
	}
}

                      }

                      public class newimage_args : EventArgs
                      {
                      public imageobject img;

                      public newimage\_args()
{
}

                      }

                      and in the main form it's called like this:

                      public Form1()
                      {
                      ...
                      ct = new camerathread();
                      ct.newimg += new newimg_handler(ct_newimg);
                      camerawork = new System.Threading.Thread(new System.Threading.ThreadStart(ct.run));
                      camerawork.Priority = System.Threading.ThreadPriority.AboveNormal;
                      camerawork.Start();
                      ...
                      }

                      void ct_newimg(object sender, newimage_args e)
                      {
                      img = e.img;
                      display(img);
                      }

                      my BIG problem is, that the gui form is not responding while the thread is waiting for an image from the device (it can be many seconds, according to the timeout property). but why? i wrote the same application in c++ and everything is working fine (but c++ is at the moment not an option, the application has to be in c#.net). i also tried asynchron BeginInvoke calls on a method which is taking the images, but the same result. it looks like it's working sequentially, like i would use a timer for getting the images. how can i make the thread completely independent working from the gui form, so i can also interact with the gui? i'm confused about the threading under .net. any hint is welcome. help regards, criss

                      K Offline
                      K Offline
                      Krzysztof Gorgolewski
                      wrote on last edited by
                      #15

                      thanks to all i bothered with my problem. i could solve it by contacting the devices support... it really just depends on my GetImage method. anyway. greetings criss

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes

                      • Login
                      • Don't have an account? Register
                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups