Return to Answer

After some more research, I just wanted to add that the correct answer for my use-case and intuitions is actually the Presenter First variant of MVP (Model-View-Presenter). It's a design pattern that pivots from the Presenter to create references for both the Model and the View, rather than starting with the View and creating the Presenter which creates the Model.

Here's the snippet for the main thread entry methods of the Presenter First pattern

Code from C# Presenter First example – VS2003 project for a sliding puzzle game

using System;
using System.Windows.Forms;
namespace wsm.Puzzle
{
 /// <summary>
 /// Summary description for PuzzleMain.
 /// </summary>
 public class PuzzleMain
 {
 [STAThread]
 static void Main()
 {
 ILoadImageModel loadImageModel = new LoadImageModel();
 ILoadImageView loadImageView = new LoadImageDialog();
 new LoadImagePresenter(loadImageModel, loadImageView);
 IImageCutter imageCutter = new ImageCutter();
 PuzzleForm view = new PuzzleForm();
 IPuzzleModel model = new PuzzleModel(loadImageModel, imageCutter);
 new PuzzlePresenter(model, view);
 model.Initialize();
 Application.Run(view);
 }
 }
}

The pattern plays very well into my kind of scenarios where my controls come from PLCs (Programmable Logic Controller), sensors, cylinders, a user Form, etc... typically I deal as much or more with machine IO, than I do with humans/operators. Intuitively this pattern just feels better and makes more sense for my particular use-cases.

After some more research, I just wanted to add that the correct answer for my use-case and intuitions is actually the Presenter First variant of MVP (Model-View-Presenter). It's a design pattern that pivots from the Presenter to create references for both the Model and the View, rather than starting with the View and creating the Presenter which creates the Model.

Here's the snippet for the main thread entry methods of the Presenter First pattern

Code from C# Presenter First example – VS2003 project for a sliding puzzle game

using System;
using System.Windows.Forms;
namespace wsm.Puzzle
{
 /// <summary>
 /// Summary description for PuzzleMain.
 /// </summary>
 public class PuzzleMain
 {
 [STAThread]
 static void Main()
 {
 ILoadImageModel loadImageModel = new LoadImageModel();
 ILoadImageView loadImageView = new LoadImageDialog();
 new LoadImagePresenter(loadImageModel, loadImageView);
 IImageCutter imageCutter = new ImageCutter();
 PuzzleForm view = new PuzzleForm();
 IPuzzleModel model = new PuzzleModel(loadImageModel, imageCutter);
 new PuzzlePresenter(model, view);
 model.Initialize();
 Application.Run(view);
 }
 }
}

The pattern plays very well into my kind of scenarios where my controls come from PLCs (Programmable Logic Controller), sensors, cylinders, a user Form, etc... typically I deal as much or more with machine IO, than I do with humans/operators. Intuitively this pattern just feels better and makes more sense for my particular scenarios.

I should also note that Steven Doggart and Dan Lyons were both correct about the irrelevance of multithreading in my original question. The proposed question actually missed the point of the real problem I had.