Hi John, I think either you're over-analyzing this, or the problem is in fact much bigger than MVC. :)
Let's forget about MVC for a moment, and consider a much more common scenario: WM_PAINT. Do the View objects know how to render themselves, without asking anything of the Document? Probably not. But alas, if the Document state is locked by a long-running operation on a background thread... well, the app is just going to suck. I think that the best (only?) solution may be to revist the background thread's design, and employ a much more fine-grained approach to locking and releasing the Document's state. At the end of the day, the whole "don't block the UI thread" rule is a subjective one -- all cpu instructions take some finite amount of time to complete, so what constitutes "blocking"? (A few simple math instructions? Definitely not. Long division? Probably not. Calculating pi to 3 million decimal places? Probably. Oops, where did we cross over?) So, if you can reengineer the background thread such that it never locks the Document for more than N cpu cycles (where N is some arbitrary-but-acceptably-small number to achieve good UI responsiveness), that's what I'd recommend. Off the top of my head, the only cases I can think of where that might not be possible are pretty exotic. Like, if our Document class is/has an XmlDocument, and we have to lock the whole shebang during a long-running XSL transform operation -- the crux being, we don't own the source to the XSLT engine, and so we can't achieve any finer-grained locking. In an exotic case like that, it might be best to fork off a clone of the Document object; let the worker thread crunch on that while the View objects still have (at least readonly) access to the original Doc. Then, when the transform is complete, swap out the doc and fire a DocumentChanged event so the views can repaint themselves. Cheers, -Shawn http://www.windojitsu.com/ -----Original Message----- From: John Elliot [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 20:26 Subject: Re: Thread with message pump (UI thread) > I'm not certain that I understand your situation completely, but I don't > see any issues that wouldn't be handled by using BeginInvoke rather than > Invoke. That will let both UI and process threads proceed without waiting > on the other. 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. =================================== 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 =================================== 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
