If the UI never accesses the model directly (which would require locking to avoid possibly getting inconsistent data if the model is in the process of being updated), but only sends requests (via BeginInvoke) to the model thread for information, does that solve the problem?
The UI thread will update the display using information passed in event-handler parameters (as you indicated was a possibility), or it can use BeginInvoke to send a request for model state to the model thread and uses the results that (eventually) come back to update the display. (The latter could happen if the user pressed a Refresh button, or expands a tree node whose contents only exist in the model, or some such.) If the user does something in the UI that should cause an update to the model, the UI thread uses BeginInvoke to pass the "update model" request. In the same way that only the main thread touches the UI, only the model thread ever touches the model's state. Doesn't that make anything that does updates (to either UI or model) single threaded so that no locking is needed, and everything executes in sequence? The biggest annoyance is that you either need to (A) define all the interactions between the UI thread and the model thread in code that they share (so the development has to be done by one person, or by people that communicate constantly); or you need to (B) develop a very flexible mechanism for sending data in event-handler parameters (to the UI) and requesting data (from the model). B allows development to proceed without a lot of shared code (EventArgs descendents and method signatures) being to be updated constantly. At 11:26 PM 2/27/2004, John Elliot wrote (in part) >I was implying that I would use BeginInvoke, so that each thread could >execute concurrently. My problem is that even if both threads are >executing concurrently, if they try and share resources for which there >might be some contention, then a resource could be locked, and one >thread could block while waiting for it. Meaning that I could block the >UI thread, which is something I'd like to avoid. > >So my two considered solutions were to either: >A: Not rely on the shared resource for state, but rather pass state with >the event, or >B: Create a 'message pump', where I can queue event delegates and invoke >them once the worker thread has finished. > >It may be the case that I don't need to worry about this, but then there >will be resource contention, and I'm not sure if this is a good idea. >Also, what if the state objects were not thread safe? Then I'd have to >use one of the methods left above, or risk using bogus data. > >I'm still looking for an async MVC pattern for WinForms. Anyone know >anything about this? > >Basically the Model contains state and throws events, and the Views >receive the events so they can update themselves in the UI. But the >Models state is changed on a worker thread, and the Views need to update >themselves on the UI thread. But the code on the UI thread that updates >the View can't ask for data from the Model while it is possible that the >model is being manipulated by a worker thread, because the worker thread >may have locked the Model causing the UI thread to block. > >John. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
