Progress bar requirement as sufficient justification for multithreading via BackgroundWorker?

Question

Taken as given that multi-threaded applications are debugging hell and should be avoided at all costs...

Is the requirement to display of a progress bar a sufficient reason to enter multi-threaded land?

Specifically, let's say a C# windows forms .NET 3.0 application needs to download a 100MB file. Is it right to multi-thread (via a BackgroundWorker component) to do the download on that thread so that the UI thread is free to update a progress bar showing progress?

Sorry if this question is a bit fuzzy. I've not done anything multi-threaded before.

Answer 1

You have not said anything about what language are you using; in C#, for instance, you could use WebClient with DownloadFileAsync and DownloadProgressChanged

While this is a multi-threaded program, I consider it as low complexity program.

Answer 2

When you're creating a GUI application, the main problem with doing everything on the UI thread, is that it might freeze your application while for example waiting for I/O. So if you don't have anything that might freeze the application for long enough to annoy the user (and that time is very subjective of course), then go ahead with single threaded applications. But otherwise, I guess the question is how much you value the user experience.