I need to write a library class that performs timing operations, and raises a tick event periodically. I need this library to be usable from both WinForms and non-WinForms applications.
The problem is that the threading model is quite different for different types of applications. WinForms apps even have their own dedicated timers, but I don;t know in advance what type of app will be calling me.
Is there an established pattern for safely raising a timer event without prior knowledge of the type of app (WinForms, WPF, Silverlight, ASP.NET, etc.) that will use it?
Is there an established pattern for safely raising a timer event without prior knowledge of the type of app (WinForms, WPF, Silverlight, ASP.NET, etc.) that will use it?
There are timers that are platform neutral in the framework: System.Threading.Timer and System.Timers.Timer. However, these will both require you to handle the marshaling back to your synchronization context, as they raise their events on a threadpool thread.
You could provide this marshaling in a generic way - ie: make a "timer" class that wraps one of the above, taking a SynchronizationContext as an argument. When the timer's Tick event occurs, you could Post the data back to the context. This is, effectively, what the Windows Forms timer does.
You'd then just create it in your UI thread and pass SynchronizationContext.Current to the "new timer" class. This would work for Windows Forms, WCF, WPF, Silverlight, etc - as they all setup a SynchronizationContext on their "main" thread.
Related
Consider a basic WPF line-of-business application where the server and clients both run on the local network. The server simply exposes a Web API which the clients (running on desktop computers) call into. The UI would consist of CRUD-style screens with buttons to trigger calls to the server.
In my original version of the app none of these UI operations were asynchronous; the UI would freeze for the duration of the call. But nobody complained about the UI becoming unresponsive, nor did anyone notice; the calls were typically less than a quarter second. On the rare occasion if the network connection was down, the UI would freeze for as long as it took for the operation to timeout, which was the only time that eyebrows were raised.
Now that I’ve begun implementing async/await for all server calls, it has quickly become apparent that I have a new issue on my hands: the complexities of dealing with re-entrancy and cancellation. Theoretically, now the user can click on any button while a call is already in progress. They can initiate operations that conflict with the pending one. They can inadvertently create invalid application states. They can navigate to a different screen or log out. Now all these previously impossible scenarios have to be accounted for.
It seems like I’ve opened up a Pandora’s Box.
I contrast this to my old non-async design, where the UI would lock-up for the duration of the server call, and the user could simply not click on anything. This guaranteed that they couldn’t foul anything up, and thus allowed the application code to remain at least 10x simpler.
So what is really gained by all this modern approach of async-everywhere? I bet if the user compared the sync and async versions side-by-side, they wouldn’t even notice any benefit from the async version; the calls are so quick that the busy indicator doesn’t even have time to render.
It just seems like a whole tonne of extra work, complexity, harder-to-maintain code, for very little benefit. I hear the KISS principle calling…
So what am I missing? In an LOB application scenario, what are the benefits of async warrant the extra work?
So what is really gained by all this modern approach of async-everywhere?
You already know the answer: the primary benefit of async for UI apps is responsiveness. (The primary benefit of async on the server side is scalability, but that doesn't come into play here).
If you don't need responsiveness, then you don't need async. In your scenario, it sounds like you may get away with that approach, and that's fine.
For software that is sold, though - and in particular, mobile applications - the standard is higher. Apps that freeze are so '90s. And mobile platforms really dislike apps that freeze, since you're freezing the entire screen instead of just a window - at least one platform I know of will execute your application and drop network acess, and if it freezes, it's automatically rejected from the app store. Freezing simply isn't acceptable for modern applications.
But like I said, for your specific scenario, you may get away without going async.
i'm using C++ managed 2010 for designing a GUI in a form.h file. The GUI acts as a master querying data streaming from slave card.
Pressing a button a function (in the ApplicationIO.cpp file) is called in which 2 threads are created by using API win32 (CREATETHREAD(...)): the former is for handling data streaming, and the latter is for data parsing and data monitoring on real time grpah on the GUI.
The project has two different behaviour: if it starts in debugging mode it is able to update GUI controls as textbox (using invoke) and graph during data straming, contrariwise when it starts without debugging no data appears in the textbox, and data are shown very slowly on the chart.
has anyone ever addressed a similar problem? Any suggestion, please?
A pretty classic mistake is to use Control::Begin/Invoke() too often. You'll flood the UI thread with delegate invoke requests. UI updates tend to be expensive, you can easily get into a state where the message loop doesn't get around to doing its low-priority duties. Like painting. This happens easily, invoking more than a thousand times per second is the danger zone, depending on how much time is spent by the delegate targets.
You solve this by sending updates at a realistic rate, one that takes advantage of the ability of the human eye to distinguish them. At 25 times per second, the updates turn into a blur, updating it any faster is just a waste of cpu cycles. Which leaves lots of time for the UI thread to do what it needs to do.
This might still not be sufficiently slow when the updates are expensive. At which point you'll need to skip updates or throttle the worker thread. Note that Invoke() automatically throttles, BeginInvoke() doesn't.
Ye Olde Add Web Reference generates XXXAsync calls to services that use eventing to inform the caller that the call had completed.
Add Service Reference in something like a WPF or console app, when told to generate async operations, uses the IAsyncResult design pattern (BeginXXX and EndXXX operations). My understanding is that this was generally regarded as a step forward in usability and flexibility - you can use a callback, you can begin blocking at any point in time simply by calling EndXXX, you can group wait handles and block on a set of operations, you can poll, etc.
Why doesn't ASR in Silverlight use IAsyncResult? My guess is because the designers wanted to make it very clear that full asynchronicity is in fact required, and if they had used the IAsyncResult design pattern, it would have been too easy to try just call Begin immediately followed by End, which would have made for a stumbling block that would have been hit by roughly 100% of new devs or people who didn't have a good grasp of async.
The Silverlight team provided immediate access to the event based async pattern because it's an easier to use approach (but a lot less flexible). For example, the event is fired in the display thread, allowing developpers unwilling to think about their thread model to forget about it.
If you need better flexibility (as me), the Begin/End async pattern is available for Silverlight too. In fact the event based generated code is based upon the IAsyncResult one.
Your generated Channel interface defines the begin/end methods, and you can use the channel factory to obtain an usable implementation of the interface.
From MSDN:
Usually, the event-based asynchronous model described previously raises the completion event on the same thread on which the service was called. This is convenient in many applications, because you often invoke services from the UI (User Interface) thread, and can update UI components (such as text boxes in our example) directly in the completion event handler.
Occasionally, you may want the completion event to be processed on a background thread. Either for this or for other reasons, you may want to use an alternative asynchronous invocation model based on the IAsyncResult mechanism and on Begin/End methods.
To use this model, you must first cast the proxy to an appropriate interface type. The interface type is generated automatically alongside the proxy by the Add Service Reference tool. You can then invoke the appropriate Begin method.
CopyIAsyncResult iar = ((CustomerService)proxy).BeginGetUser(userId, GetUserCallback, proxy);
Thanks to Kimberly for the MSDN link.
howzit!
I'm a web developer that has been recently requested to develop a Windows forms application, so please bear with me (or dont laugh!) if my question is a bit elementary.
After many sessions with my client, we eventually decided on an interface that contains a tabcontrol with 5 tabs. Each tab has a datagridview that may eventually hold up to 25,000 rows of data (with about 6 columns each). I have successfully managed to bind the grids when the tab page is loaded and it works fine for a few records, but the UI freezes when I bound the grid with 20,000 dummy records. The "freeze" occurs when I click on the tab itself, and the UI only frees up (and the tab page is rendered) once the bind is complete.
I communicated this to the client and mentioned the option of paging for each grid, but she is adament w.r.t. NOT wanting this. My only option then is to look for some asynchronous method of doing this in the background. I don't know much about threading in windows forms, but I know that I can use the BackgroundWorker control to achieve this. My only issue after reading up a bit on it is that it is ideally used for "long-running" tasks and I/O operations.
My questions:
How does one determine a long-running task?
How does one NOT MISUSE the BackgroundWorker control, ie. is there a general guideline to follow when using this? (I understand that opening/spawning multiple threads may be undesirable in certain instances)
Most importantly: How can I achieve (asychronously) binding of the datagridview after the tab page - and all its child controls - loads.
Thank you for reading this (ahem) lengthy query, and I highly appreciate any responses/thoughts/directions on this matter!
Cheers!
There's no hard and fast rule for determining a long-running task. It's something you have to know as a developer. You have to understand the nature of your data and your architecture. For example, if you expect to fetch some info from a desktop database with a single user from a table that contains a couple dozen rows you might not even bother showing a wait cursor. But if you're fetching hundreds of rows of data across a network to a shared database sever then you'd better expect that it will potentially be a long-running task to be handled not simply with a wait cursor but a thread that frees up your UI for the duration of the fetch. (You're definitely on the right track here.)
BackgroundWorker is a quick and dirty way of handling threading in forms. In your case, it will very much tie the fetching of data to the user interface. It is doable, works fine but certainly is not considered "best practice" for threading, OOP, separation of concerns etc. And if you're worried about abusing the alocation of threads you might want to read up on the ThreadPool.
Here's a nice example of using asynchronous threading with the thread pool. To do data binding, you fetch your data in the thread and when you get your callback, simply assign the result set to the the grid view's datasource property.
I have a very bad feeling about using lock in my code but now the Dispatcher of WindowBase exists and I want to use it everywhere.
For example I use a multi thread singleton WCF service who publish events on the EventAggregator of PRISM, the payload is immutable (it is just data) and every thread with a dispatcher can retrieve the event gracefully, whitout deadlock in their own dispatcher. (Not only UI thread, but also threads with database calls, threads with services call, threads which log or other threads with slow calls, because I don't want to freeze the UI).
But my problem is that this Dispatcher is coupled with WPF so I feel a bit guilty when I use it everywhere, I feel that the dispatcher was not created for my use case in mind.
Does it exist another Dispatcher implementation not coupled with WPF ? or that's OK to abuse it ?
Thanks,
Update
The solution that Paul Stovell give to me is to create an interface IDispatcher, and an adapter for the Wpf Dispatcher, so this will be easier to test !
This solution was good for me because, I refactored my tests and I can now use a SynchronousDispatcherAdapter in my tests (Thanks to it, I don't have to use the Dispatcher of WPF in my tests).
Using the Dispatcher instead of a BackgroundWorker make sense, because I'm using a multi publisher / subscriber pattern (with PRISM), and thanks to the Dispatcher every event handler are called on threads who subscribe them to the event. This means that the only point where multi threading issue can happen is at the payload of my event (I made him immutable).
My different threads don't communicate directly between them they can just publish and subscribe to event.
Thus, database calls, logs calls, services calls, UI calls run on different threads and don't know about each other (they only know about events they subscribe and publish).
The background worker will make sense, when I will make some calls from my UI to a repository.
But I hope to find a design without using BackgroundWorker because I prefere to use this subscriber/publisher pattern (I think it makes my code more readable)
The main issue with using the Dispatcher (or BackgroundWorker) is that it's difficult to test, unless your testing harness actually has a UI thread.
Solution 1
Use the SynchronizationContext. It provides the same ability to invoke on the UI thread and works in Windows or WPF. Testing it also possible.
Solution 2
Think of the dispatcher as being just another service. As you use PRISM, you are familiar with services and IOC. Here is how such a service may be used:
// Not a UI component
public class MyDomainService : IMyDomainService
{
private readonly IDispatcher _dispatcher;
public MyDomainService(IDispatcher dispatcher)
{
_dispatcher = dispatcher;
}
private void GotResultFromBackgroundThread()
{
_dispatcher.Dispatch(() => DoStuffOnForegroundThread());
}
}
This allows you to substitute in different implementations for your platform/testing.
Here is an example of IDispatcher, a WPF implementation and a test implementation. You would register them with your IOC container just like any other service, and they are available to both UI and other services.
yes and no.. its a rendering thing..not a threading thing per se..
The Dispatcher selects work items on a priority basis and runs each one to completion. Every UI thread must have at least one Dispatcher, and each Dispatcher can execute work items in exactly one thread. as per this this link from Microsoft.
You still have to handle on your own any threads you start yourself.
Check this one for info on: Multithreaded Programming with the Event-based Asynchronous Pattern
Personally I use the Background Worker for my threading needs.
Best Practices here.
I'm going to necro the heck out of this, but this sounds like a bad idea. What you are saying is that you need a queue for your publisher to dump items on for its subscribers. A Dispatcher, at its core, is just a glorified queue, with a LOT of overhead around it. The overhead is specifically for protecting access to UI resources, which you aren't using. That suggests it's the wrong thing to use.
The person who suggested a SynchronizationContext is on a good path. This accomplishes what you want (safely marshalling data to another thread), without tying you to a UI concept. You could write an extension method which marshals your event to the SynchronizationContext requested by each subscriber of the event (it is available by casting the Target of your subscribing Delegate to ISynchronizeInvoke. The result of that cast will allow you to know if it needs to be marhalled, and can do it automatically for you.
Even better would be to just use a queue with appropriate locking semantics. The overhead of the lock is unlikely to be an issue, and if it is, your use of the Dispatcher would be far more destructive than a simple lock. In this case, simpler is better. They key would be to only keep the lock to add/remove an item from the queue. Your subscribers should perform whatever work they do outside of the lock.