BackgroundWorker Using a COM Object Results in UI Thread Hangup

Question

I have a dedicated class that includes a BackgroundWorker that is responsible for running class-specific actions from a queue - actions which require use of a COM object.

Objects the dedicated class are created during runtime from the UI thread when the application starts up (WPF). When the class' constructor is called, it instantiates a BackgroundWorker that runs asynchronously dequeuing Actions assigned from the UI thread.

However, when these Actions require data resulting from the COM object, I notice that the UI thread is waiting on the BackgroundWorker to finish the Action before reacting to user input.

How can I isolate so that the UI thread is not impacted by the COM's functions that can take up to 10 seconds to complete?

Code:

public class User(){
  private BackgroundWorker Worker;
  private Queue<Action> ActionQueue;
  private COM COMObject; // COM is an interface exposed by the COM referenced in VS project
  private bool Registered;

  public User(){
    this.Registered = true;
    this.ActionQueue = new Queue<Action>();
    this.Worker = new BackgroundWorker();
    this.Worker.DoWork += new DoWorkEventHandler(DoWork);
    this.Worker.DoWork += new RunWorkerCompletedEventHandler(WorkerCompleted);
    this.Worker.Worker.WorkerSupportsCancellation = true;
    this.Worker.Worker.RunWorkerAsync();
    this.COMObject = new COM();
  }

  private DoWork(object sender, DoWorkEventArgs e){
    // If there is something to be done (an action) in the queue
    if (ActionQueue.Count > 0){
      // Dequeue the action from the queue
      Action queuedAction = ActionQueue.Dequeue();

      // Do the action
      queuedAction();
    }
  }

  private void WorkerCompleted(object sender, RunWorkerCompletedEventArgs e){
    // While this machine continues to be registered to the app...
    if (this.Registered)
    {
        Worker.RunWorkerAsync();
    }
  }

  public void ConnectToDatabase(){
    Action action = delegate {

      COMObject.Connect(); // function can take up to 10 seconds to return 
      
    }; // end of action delegate

    ActionQueue.Enqueue(action);
  }
}

Use Code (in UI thread):

User user = new User();
user.ConnectToDatabase();

In my UI, during application startup, there can be up to 10 User objects created and called to connect. If I comment out the COMObject.Connect(); line in User::ConnectToDatabase and replace with Thread.Sleep(10000) the UI thread does not wait 10+ seconds. But, as is the code now, I notice that the COMObject.Connect(); line does result in 10+ seconds before any user input in the WPF app is processed again.

How can I isolate so that the functions related to the COM object do not impact the performance of the UI thread?

(Note: there is no interaction with the UI thread from the actions queued with the BackgroundWorker. Only class-specific properties are changed in those actions).

For the record, not only are you doing COM operations on the main thread directly (`new COM()` happens on the UI thread), but you should look up the `STAThread` attribute you most likely put on your main function. Also, don't use `Queue<>` like that between threads, you're asking for a crash. — Blindy, Jun 29 '20 at 19:00
The following is blocking the user code : this.COMObject = new COM(); You can move this line of code to WorkerCompleted event. The workerComp[leted Event does not have to be inside the BackGroundWorker. So I would move to outside the so rest of code can get access to the data. — jdweng, Jun 29 '20 at 19:07
@Blindy - the Queue holds Actions specific to a thread (nothing relating to functions b/w any other thread), would that still pose a risk? — Dash, Jun 29 '20 at 19:08
It doesn't matter what it holds, you're enquing in the UI thread and dequing on the background worker's thread, that's a clear recipe for disaster. — Blindy, Jun 29 '20 at 19:10
Related: [Forcing certain code to always run on the same thread](https://stackoverflow.com/questions/61530632/forcing-certain-code-to-always-run-on-the-same-thread) — Theodor Zoulias, Jun 30 '20 at 01:29
It's a feature, a COM library class can tell the infrastructure that it is not thread-safe. Using it in a thread anyway begets the kind of behavior you see, the infrastructure uses the equivalent of Dispatcher.Invoke() to keep it thread-safe. So the slow code runs on the UI thread, there is no free lunch. BackgroundWorker is unable to solve this problem, you have to create your [own thread](https://stackoverflow.com/a/21684059/17034). — Hans Passant, Jun 30 '20 at 22:55

score 0 · Accepted Answer · answered Aug 06 '20 at 20:10

The answers always lurk in the comments :)

As @Blindy and @jdweng pointed out, the new COM() was being called on the main UI thread, whereas all the functionality of the COM object was being used on a different thread.

In addition, I did set the COM object's thread with the STAThread attribute (this.Worker.SetApartmentState(ApartmentState.STA);).

And, I did change from using a BackgroundWorker to an actual Thread.

And, last, but not least, as @Blindy called out the issue with using a Queue<Action> to do work on the Worker thread, queued from the main UI thread, I did end up using a ConcurrentQueue<Action>, per @Anders H's suggestion. I would have used Tasks, which from the amount of research I did on the topic would have solved the cross-thread access potential issue, but, because queued "work" would have to be done sequentially and relating to the COM object, the ConcurrentQueue ended up seeming like a decent solution for the time being. But, will have to revisit this later on.

BackgroundWorker Using a COM Object Results in UI Thread Hangup

1 Answers1