2

I have a C# Winforms application that talks to a USB device through a vendor library. I run this interface with a background thread. During the vendor constructor, the entire Winforms application GUI is frozen. One core of the CPU is at 100%, but the other cores are idle. How do I determine what calls the vendor is making to block the GUI?

I run the background thread like this -

public HardwareInterfaceClass() {
    var hardwareThread = new Thread(HardwareInterfaceThread);
    hardwareThread.IsBackground = true;
    hardwareThread.Name = "USB Interface Communication";
    hardwareThread.Start();
    return
}


private void HardwareInterfaceThread() {

  var usbInterface = new USBInterfaceHardware(0);  // Takes 5 seconds and blocks GUI
  ...

}
Mike
  • 1,276
  • 4
  • 16
  • 27
  • 2
    Does it block the UI or is it just very busy? – Patrick Hofman Dec 11 '14 at 13:10
  • Did you ever call anything in that API with your main thread? because they could have captured your `SynchronizationContext` and posted work items in it. – Sriram Sakthivel Dec 11 '14 at 13:14
  • 6
    Is this third party DLL perhaps suffering from affinity with the main thread? I had this once, I had to make sure all objects were created on the other thread. Can't remember if this had anything to do with STA / MTA. – Adam Houldsworth Dec 11 '14 at 13:14
  • 1
    Is it a *must* to construct it after form is shown? You could show splash screen, then init this object, then show form and start using it. – Sinatr Dec 11 '14 at 13:19
  • @Patrick Hofman - the GUI is blocked, menu selections etc have no effect until the vendor constructor completes. – Mike Dec 11 '14 at 13:41
  • @Mike is what I would want to say with my answer – faby Dec 11 '14 at 14:21
  • inside HardwareInterfaceThread() can you try putting some writelines and check where it get blocked ?? May besounds crazy but it should give the place it get blocks right – Kavindu Dodanduwa Dec 11 '14 at 14:51
  • Also even if we run threads if vendor's dll use high resources all the other parts of the application could get blocked/slow down – Kavindu Dodanduwa Dec 11 '14 at 14:53

1 Answers1

2

There is nothing at all in the code you posted that would block the UI thread. So there are two possibilities:

  1. There is something in the library code you are calling that is blocking the UI thread.
  2. The UI thread is not really blocked.

It's impossible to know for sure which is correct, though the first option would be very unusual, especially if you hadn't actually passed anything to the library code that would even tell it where your UI thread is (but not impossible…it could have logic internally that seeks out your UI thread and somehow messes with it).

If the second option is correct, then the UI could seem to be blocked, but simply not getting enough CPU. The fact that your other CPU cores are idle suggests this isn't the problem, but given how remote the first possibility is, it's worth at least considering.

If your background thread is taking CPU time away from the UI thread, then you can fix that by setting hardwareThread.Priority = ThreadPriority.BelowNormal;. Indeed, this is a good idea to do for any thread that spins consuming 100% of a core's CPU time.

There is, of course, a third possibility: in your own code, you have somehow caused the UI thread to be blocked while this background thread is working. But without a concise, complete code example it would be impossible to explain where that is. We can only look at the code you posted, and that code doesn't block the UI anywhere.

Peter Duniho
  • 68,759
  • 7
  • 102
  • 136