C# Programming
12-01-2009, 03:51 PM
Hi!
I am trying to set up a generic framework for applications following the Model Controller View pattern with a (main) GUI thread and a worker thread actually handling the data. I want this to reliable prevent the GUI from freezing and to enforce strict GUI/data/algorithm separation.
My idea is to have one single Worker thread in order to rid me off the problem of having to make all data accesses thread safe(?!), since there is just this one thread accessing the data.
So I would have the main thread containing the GUI and a Worker Thread for Model/Controller. The worker thread would start up when the application starts and close down when the application closes.
For the general setup I could think of a Producer/Consumer pattern with a worker thread that has a ThreadedQueue, that is the GUI thread can dispatch jobs to the Controller in the worker thread wich are then processed in the order they have been enqueued.
For simplicity the Controller can have a state machine (simplest busy/idle) that could actually prevent jobs being enqueued while it's too busy.
Now the practical problem I have is how to set up communication across the threads as needed in the MCV pattern? The main issue I see is that the View might request data from the model while the controller is actually changing this data.
Thus my idea was to have the View issue a job to the controller that requests the data and supplying a callback/delegate to be called from the Controller/Model. Since the callback is called from the Model/Controller thread it is positively thread safe if the callback is blocking and does not return before the data has actually been read by the View (using Invoke() within the GUI Form/Control functions).
Could this work, or did I oversee something obvious here ?
Does anyone know about some good ideas on this or a hint to some article where something similar is described?
I am trying to set up a generic framework for applications following the Model Controller View pattern with a (main) GUI thread and a worker thread actually handling the data. I want this to reliable prevent the GUI from freezing and to enforce strict GUI/data/algorithm separation.
My idea is to have one single Worker thread in order to rid me off the problem of having to make all data accesses thread safe(?!), since there is just this one thread accessing the data.
So I would have the main thread containing the GUI and a Worker Thread for Model/Controller. The worker thread would start up when the application starts and close down when the application closes.
For the general setup I could think of a Producer/Consumer pattern with a worker thread that has a ThreadedQueue, that is the GUI thread can dispatch jobs to the Controller in the worker thread wich are then processed in the order they have been enqueued.
For simplicity the Controller can have a state machine (simplest busy/idle) that could actually prevent jobs being enqueued while it's too busy.
Now the practical problem I have is how to set up communication across the threads as needed in the MCV pattern? The main issue I see is that the View might request data from the model while the controller is actually changing this data.
Thus my idea was to have the View issue a job to the controller that requests the data and supplying a callback/delegate to be called from the Controller/Model. Since the callback is called from the Model/Controller thread it is positively thread safe if the callback is blocking and does not return before the data has actually been read by the View (using Invoke() within the GUI Form/Control functions).
Could this work, or did I oversee something obvious here ?
Does anyone know about some good ideas on this or a hint to some article where something similar is described?