频繁，可取消的异步大文件读取操作（.NET 4.0）

Question

My application graphically visualizes very large files. The user can zoom in and use a scrollbar to move over it. Because accessing file contents would cause UI delays and piss off the user, file access needs to be done from a separate thread.

Case: user moves scrollbar:

• the thread (start a new one each time?) must load data in the background to update the view for the new scrollbar position
• if a prior request is in progress: that must be cancelled
• when it has loaded the data it must return the result to the UI for display

For file access I will use the MemoryMappedFile class. Maybe it's thread safe, but I think it's better to completely stop a previous read operation before starting a new one (no overlap, sequential ).

I was thinking cancelling requests using CancellationTokenSource s. But a scrollbar generates many events. Are we supposed to new and cancel tens or hundreds of CancellationTokenSource s in a short time? ( frequent starting/cancelling )

There's an overhead starting a thread, even with a thread pool. So it's better to have a thread ready, waiting for work posted to it. Dispatcher ?

BackgroundWorker may have the overlap problem if you starting a new one each time. But that's how it's supposed to be used...

'async' 'await' : I hear this is very good for IO, but I'm on .NET 4.0 so it's not available for me.

So now I'm thinking a Thread with Dispatcher , and CancellationTokenSource to cancel requests. But maybe there's a better way?

Answer 1

This question as stated seems way too broad; it lacks any context (ie what have you tried so far, what specific problem did you have?) and there are far too many different questions. So, let's assume we constrain the scope of the question to something that is of reasonable breadth for Stack Overflow.

As such, in terms of the posted question above, only brief comments regarding those questions would be appropriate:

MemoryMappedFile

That class does not offer asynchronous access at all, so I don't know why it's even here, never mind why you've chosen it as your underlying implementation.

"scrollbar generates many events"

One typically does not initiate costly operations (computation or I/O) in response to every UI input; instead, you wait a small period of time, and only start after that. This will dramatically reduce the number of operations started as the user provides input (eg manipulates the scroll bar); if you make the delay long enough, you'll almost never have to interrupt an asynchronous operation that's in progress.

"overhead...even with a thread pool"

Huh? what is a thread pool other than an implementation in which there's "a thread ready, waiting for work posted to it" , just as you propose to implement yourself?

There is not going to be any overhead using ThreadPool that you would not yourself introduce were you to reinvent the thread pool yourself.

BackgroundWorker may have the overlap problem

What overlap problem? The same exact one you'd have with any other asynchronous implementation, ie that one operation is in progress when you want to start another?

BackgroundWorker is just another way to implement background tasks, which in turn are one way to implement certain kinds of asynchronous operations. The main benefit of BackgroundWorker isn't that it encapsulates a task; the ThreadPool does that fine all by itself. What BackgroundWorker offers is events that are raised in the synchronization context in which the object was created (eg the UI thread), to simplify reporting of progress, cancellation, and completion.

If there's an "overlap problem" at all, it's nothing that doesn't also exist with any other asynchronous code you might implement.

async / await

This C# 5 feature does not in and of itself solve any asynchronous problem. It is simply a syntactical way to leverage the compiler's ability to vastly simplify how asynchronous code is written. The features works with actual asynchronous implementations, not as some alternative to those.

It is my hope that the points above help you in your path to coming up with an actual implementation of whatever it is you're trying to do. If and when you have actual code and run into some specific problem that you need help with, please do post a new question, including a good, minimal , complete code example that reliably reproduces whatever problem you are having, along with a precise, detailed explanation of what that code does and how that's different from what you want.