Control.Invoke uses SendMessage internally and Control.BeginInvoke uses PostMessage.
Regards Richard Blewett DevelopMentor > -----Original Message----- > From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of John Davis > Sent: 01 March 2004 11:48 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread) > > Yes, Control.Invoke uses the message pump. The message pump is the queue > you speak of. I'm guessing the mechanism uses a PostMessage with a > WM_USER > + x. > > ----- Original Message ----- > From: "John Elliot" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, March 01, 2004 5:34 AM > Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread) > > > > > 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? > > > > I'm not sure that you can 'BeginInvoke onto the model thread'. As I > > understand it (please correct me if I'm wrong), if I have a delegate I > > can call BeginInvoke and it will be serviced by a worker thread from the > > thread pool. I'm not sure that a 'worker thread from the thread pool' is > > synonymous with 'model thread'. > > > > There are some gaps in my understanding around this however. For > > example, how is it that Control.BeginInvoke allows the delegate to find > > its way into the code path on the UI thread? The delegate must be added > > to a queue and serviced at some point right? Which queue? Does it use > > the message pump? If so, what sort of message does it send? Where can I > > read about the mechanics of Control.BeginInvoke? > > > > The way I'm trying to think about it at the moment is that I have two > > main threads. The 'UI thread' and the 'application thread'. The UI > > serves two purposes: > > > > 1. Represent the model (view) > > 2. Command the model (controller) > > > > My goal is to keep the UI as free as possible, basically the only > > reasons for this are so that it can paint, respond to user requests that > > don't rely on the model, or to 'cancel' something that is in progress. > > It seems that a massive amount of work needs to be done to achieve these > > relatively humble goals. > > > > The reason that this is hard in my particular case is that I have an MDI > > WinForms application that shares data from a local (in-process) 'model' > > of the data from the database. I don't use Dataset etc. because I run > > into all sorts of trouble with a user fighting *with themself* over read > > locks (i.e. timestamp/rowversion), defining complex relationships > > between data that hasn't been allocated a primary key, etc. I use my own > > business objects and collections to help me manage these relationships, > > basically I'm building my own object-relational wrapper that is the main > > component of the 'Model' in my MVC application. > > > > There are a few hairy design challenges. I want my model to be equally > > usable in both a web based and WinForms based application. It gets > > pretty challenging though, because the 'model' is designed for 'client > > side' representation of data (I have a stateless application server that > > can service requests and commands to populate the client-side model or > > persist it to a data store) and these two execution contexts are quite > > different. > > > > In a web based app, multiple users share a process, and if two users > > were editing the same domain object (say, Employee, Invoice, etc.) then > > I'd let them do it, and fail with an optimistic concurrency error ASAP > > (to avoid them wasting their time). A web based app is largely > > request-response, and so is simple in this regard. The user takes a read > > lock (in the virtual, optimistic concurrency sense) on a 'smallish' > > amount of data and then submits changes to that data, assuming there has > > been no resource contention during the period that they were editing the > > data I can just apply their changes, otherwise I can take them into a > > 'merge' process (heh, or fail them ;). Obviously, pessimistic > > concurrency has a whole heap of problems (particularly with a web based > > system) so I choose optimistic concurrency as the lessor of two evils. > > > > But an MDI WinForms app is quite different because it offers a more > > sophisticated UI. In a windows based app, if I have the same domain > > object open in two views, and I alter one view, then I don't want: > > A. the other view to continue displaying stale data > > B. the user to have a concurrency problem when they flip to the other > > view later and make an edit (to the now stale data) > > > > I'd really like my business model to be resilient in the face of > > 'disconnection' too. So a user can carve off some existing data, enter > > new data, specify complex relationships, and pump it all back into the > > live system much later. I'd like to get as much support for this into > > the business model (and related APIs) as possible, but this is largely > > beside the point at the moment. > > > > I've already dealt with a lot of these problems, and I'm pretty happy > > with what I've got (it's too complex for me to really go into via this > > e-mail). > > > > I would describe what I have client-side in my MDI WinForms application > > as an MVC application. I know that people argue about what MVC is, and > > have different ideas about it. The scope of the problem that I'm trying > > to describe here though, is that given this 'static' client-side model: > > reading from it, updating it, etc. is all (relatively) straight forward > > if all my processing happens synchronously on the UI thread. The problem > > is that the UI thread is not free to respond to the user or paint itself > > while it is processing, such processing pretty much always involves > > going over the wire to the application server with blocking requests for > > state or commands to change state (basically the CRUD). > > > > One of the particularly challenging problems is that 'View' code often > > needs to do more than just 'read' from the model, often it needs to > > 'load' data into the model, and this is a long-running process. > > Lazy-loading isn't an option if I don't want to block the UI thread, and > > really is 'programming by side-effect', because I can affect the state > > of the model by doing a read operation. Design challenges are further > > aggravated by security, caching, etc. > > > > At the moment I'm really looking at how I can use a different kind of > > messaging paradigm between the Model/View/Controller than I presently > > have. At the moment such messages are passed using multicast delegates > > (AKA events). The crux of the problem with this type of notification is > > that the message is sent synchronously as it happens. So, I'm leaning > > more towards a client/server type of messaging system (more like > > publish/subscribe than 'observer' if it's fair to try and make such a > > distinction) where I can queue the multicast delegate for invocation > > later, rather than dispatch it immediately. > > > > What I'm finding is that I now need to maintain 'message and command > > queues' that are serviced on the appropriate thread. For example, if > > code executing on the 'application thread' causes a change in state to > > the model that a view has registered interest in (by attaching an event > > handler) then rather than synchronously invoking the event so the view > > can be updated immediately, I'd like to place this event on a queue so > > that once the processing on the 'application thread' runs to completion > > and the model is returned to a 'consistent' and 'not-locked' state I can > > dispatch all the messages on this queue on the UI thread and let the > > View objects request the updated state from the appropriate parts of the > > model (with no fear of the model either being locked or in an invalid > > state). Interestingly, it seems that I also need a queue for queuing > > long-running commands (like 'Save') triggered by the user (or an event) > > on the UI thread for processing on the application thread. Then I need > > some form of mutex that ensures that either the 'controller queue' is > > being serviced XOR the 'view event queue' is being dispatched. Meaning > > really that either the UI thread is reading from the model, or the > > application thread is updating it, but neither can attempt to run at the > > same time. On the face of it, this seems like the best way to go at the > > moment, but perhaps this is a crazy idea? > > > > > 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. > > > > The 'pass state with event args' problem is interesting. Initially it > > seems like this might be valid, but after a while you realise that (as > > Shawn pointed out in his last post on this thread) you really need to > > 'clone' state objects that are not strictly 'atomic' or 'immutable' when > > you do this. Once you start adding any degree of complexity, then this > > can get completely out of control and you might have to clone thousands > > of objects just so you could send a Client.ProjectChanged event. If it > > was just Client.NameChanged I might be able to pass a string with the > > new name in the event args, but if the 'property' that changed was a > > related business object then I might have to clone it (and everything > > that it contained) just to pass the event. If the UI then wanted data > > from this cloned Project that had not yet been loaded, it would have to > > query the application server for that data. Basically my entire goal is > > to 'avoid cloning, at all, ever' on the client-side, because it can > > really hurt the working set, but more particularly because once I clone > > I have one user with duplicate read locks on the same data that they can > > cause to become stale. My other goal is to 'avoid locking, at all, ever' > > because saving myself from deadlocks is non-trivial, locking decreases > > performance, and I can still end up blocking the UI thread. Usually the > > solution to avoid one is to do the other, but I don't want to do either. > > Like I said, I want to have my cake and eat it too! :) > > > > The only way that I can see to accomplish this, is to have a 'turn > > based' system, where the UI thread has a go at reading changes, painting > > itself and queuing commands, then the application thread has a go at > > processing the command queue, updating the model and queuing > > notifications for the UI. The UI can still do 'stuff' while the > > application thread is executing, but it must guarantee not to touch the > > model. I haven't hit the point where this gets unreasonable yet, but so > > far it's only in my mind (no concept code or anything like that) so > > there may be some complexity that this introduces that is beyond my > > ability to address that I haven't stumbled across yet (if there is, it > > will most likely be with the 'controller' side of the problem, because I > > haven't had a close look into that yet). > > > > The reason that I need a 'client-side' model is that I don't want > > 'temporary state' to be maintained on behalf of clients by the > > application server. Say I have a scenario where I'm entering a new > > 'Employee'. I client the 'Create new Employee' button, and up pops a > > form. Behind the scenes there some code specified 'new Employee();' as > > the data source on this form. The user enters the name etc, but wants to > > add an 'Address' for the residential address. Given that the residential > > address is now not going to be 'null' I create a 'new Address();' and > > assign it. Now I'm starting to have complex 'temporary state' in the > > client that will need to be persisted by the application server inside a > > single transaction. If I then specified that this employees postal > > address 'was the same as their residential address' I might do something > > like this: this.Employee.PostalAddress = > > this.Employee.ResidentialAddress; Now things are getting even tougher, > > because not only have I got complex relationships that I need to model > > without primary keys that will later be specified by application server > > (or the database) but I also have to represent this change to the user > > in the user interface. So, if I had two 'AddressControl' instances that > > represented the Residential and Postal address for this Employee on the > > 'EmployeeControl' then if I changed the residential address I'd want to > > see this change reflected in the postal address control. This is a > > simple (and perhaps silly example) but it outlines the complexity that > > I'm trying to model, and should serve to demonstrate why I can't > > maintain the 'model' on the application server as easily as I can on the > > client. > > > > Anyway, that's my rant for the day. At the end of the day the way I look > > at it is that the MVC pattern (or perhaps I should say 'observer' or the > > event-driven paradigm) is as old as time, async programming is as old as > > time, and what I want is some good material where someone discusses > > methods of integrating the concepts of each. I don't really want > > asynchronous execution, what I really want is a method of keeping my UI > > responsive while I work on shared local data, it's just that async > > programming seems to be what I need to do to achieve this end. That's > > way I'm happy to simply have the 'two main threads' and just managed > > requests and notifications via queues. Obviously, in trying to do this, > > a whole lot of things need to be taken into consideration, and > > responsibilities and contracts need to be given to various components, > > I'm trying to figure out what those should be, but if someone has > > already done the work, I'd rather save myself some trouble.. :P > > > > Perhaps I should get myself a book on 'game programming'. Those guys > > have been doing stuff like this for years right? > > > > The facilities in .NET alone at the moment are not of themselves > > sophisticated enough to allow me to do everything that I want to do, so > > I really need an application framework on top of .NET to help me. > > > > Obviously there are applications that work this way. Consider how VS.NET > > works. If I have a class open in the code editor and change the class's > > name, then the name change is reflected in the drop-down list on the > > top, left and in the Class View. There is a slight delay in the UI being > > updated however, and my keystrokes aren't delayed while the UI updates > > itself (I think, I could be wrong about that), indicating that this > > 'event' has been queued and dispatched. Basically I want to know about a > > pattern for accomplishing functionality like that. Is it simply the case > > that they are using WM_PAINT, and invalidating the control? If so, then > > what is the UI thread going to do when it wants the current value for > > the class name? Lock the business model of the Class so that it can read > > out the name value, meaning that the code editor needs to acquire the > > same lock when updating? I'm sure that because of all the parsing, etc > > that would be required this software is *far* more sophisticated that > > what I'm trying to achieve, but there are elements of a similar pattern > > that must have been addressed here right? If I was to run a 'find and > > replace' operation, then I wouldn't want my code to alter the code > > editors text box, but rather the 'compile unit' or 'source file' > > business object, then have the changes reflected in the text box (the > > view). My system is not a text editor of course; it's basically a > > glorified database browser. > > > > Should I just give in and leave all my code on the UI thread? The > > reality is that in a 'typical' usage scenario the UI locks up for much > > less than 500ms during an operation, but this still sucks right? In my > > travels I've never seen any software adequately deal with all of these > > problems. > > > > 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 > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004 =================================== 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
