Develop Reference

Executing operations in Background in Windows Store apps

I am building up an universal app targeting 8.1 runtime and also new to whole .NET world.
I have some operations in my application which I want to perform in parallel, asynchronously and also in background. These operations include file upload, download (both I/O and compute bound). So I wanted to execute them In threads. I would like to process them in 3 threads. Each thread will work on the operation queue and keep waiting perpetually (in while(true) loop) unless an operation is available for execution. These threads would also pass task status or progress updates to UI.
Would also like to have these threads running on Application lock or if the app suspends . If my application terminates or if the network connections is lost these threads will stop. Also would like to cancel the operations running in the threads according to me requirements (like cancelling a file download).
My initial hunch was to use threads. But since threads are not available for windows store apps and my exploration about threading in Windows store apps revealed to use task to perform this.
I read about the Tasks Asynchrony pattern (TAP) whitepaper published by MS ,channel 9 videos from Bruce Kyle and lot of other blogs. I am convinced to use Tasks .As it runs on a thread pool which can take advantage of multi core processor and is better performing
Questions on Tasks will be
Will it be useful as background thread. Can tasks be run as a
background thread perpetually.
I don't really need my tasks to return results. The result from the
operations can be relayed to UI through events.
Do I have to schedule my tasks from a background task API when the
app suspend ?
Does the Task API fit my scenario ?
Are Background tasks in Windows same as services in Android. ?
Thanks a lot and Regards,
Saurav

Note that file uploads and downloads already happen on background threads in Windows Store apps, so you don't really need to worry about it impacting your UI at all. If you want to do computationally-expensive work also, I would just spin off a new Task whenever you want to do something asynchronously unless you have specific needs around a dedicated thread reading from a queue.
If you must a perpetual thread, do not run a busy loop waiting for work; use a signalable object like an AutoResetEventinstead) to wake it up when there is something to do. This will minimize wasted CPU power (and hence battery).
Background execution is limited in Windows Store apps; you can read about it on MSDN.

Preventing multiple threads from running same background process

I have an asp.net website with a background service running that sends queued emails every minute. The problem is we moved to a web garden (multiple worker processes) and the emails get sent multiple times (at the very same time or close to it) because multiple threads are invoking that background process.
Is there a way to assign one thread or have only one thread run this process every minute and tell the other ones to ignore it?
Thanks!

I had to use mutex locking to prevent this

Do unfinished threads hang around after my multi-threaded application fails?

My application starts multiple long-running functions/methods on their own threads. When one of these threads encounters an error, my program crashes (as expected). My question, though, is do all the threads spawned by the application stop executing? or do they hang around somewhere? If so, do I need to write another application to monitor them so I can kill them?
Thank you!

When a process finishes all threads contained in that process are terminated. A thread cannot exist outside of a process. Application crash = process termination.

If you are spawning processes from threads the processes you spawn will continue to run after the spawning process ends. You can kill the process tree in task manager and in code, but by default the spawned processes will keep running if your application ends ungracefully.
I'm assuming this is what you mean when you said
My application starts multiple long-running processes on their own threads
But maybe I'm misunderstanding what you are meaning to say

If the process which created all threads is killed/aborted, threads are aborted by the OS automatically. In other words: running process = at least one running thread, killed process = all threads terminated.

How to create threads in ASP.NET pages from CLR thread pool instead of ASP.NET pool?

If I create a new thread on an ASP.NET page the IsThreadPoolThread property is true.
First question is, is it from ASP.NET pool or CLR pool ?
Second question is, if it is from ASP.NET pool then how to create a thread from CLR and don't use ASP.NET pool ?
I need a synchronous solution for long-running requests (full story).

First off, there is no difference between the ASP.NET thread pool and the CLR thread pool. ASP.NET processes pages on the CLR thread pool, so your ASP.NET pages will always have IsThreadPoolThread == true.
I'm curious as to how you are creating your thread. Are you using the System.Threading.Thread constructor, or are you using ThreadPool.QueueUserWorkItem? If you are using ThreadPool.QueueUserWorkItem, then the threads that you are getting are coming from the regular .net thread pool.
Finally, as I have posted before, it is always a bad idea to attempt long running tasks from within ASP.NET. My general suggestion is to use a background windows service to process these requests, since ASP.NET may terminate your background thread at any point. More details here, if you must do it in IIS: http://csharpfeeds.com/post/5415/Dont_use_the_ThreadPool_in_ASP.NET.aspx

While there is a point to be made about minimizing impact on transactions and catering for the unforeseen in distributed transactions, in this example its really not necessary to reinvent IIS just because the process is long running. The whole "IIS can die at any moment" meme is IMHO greatly exaggerated.
Yes, you can manually restart IIS or app pool but so can you restart any other service which does the same job for the same effect. As for auto-recycle IIS uses overlapping worker processes and will never terminate a started thread forcefully (unless time out occurs). If that were the case we would have serious problems with any hosted application (what's to stop IIS from killing a fast response thread 0.001ms after start)
In essence, let the IIS do what IIS does best and don't insist on sync operation, you'll just waste pool's thread waiting for blocking I/O which is what I believe you are trying to avoid. You already made a good choice by going to Asynchronous Handlers (ASHX), use IHttpAsyncHandler implementation to spawn your custom thread which will then block to your heart's desire without affecting the web application and its pool. Once you initiate an async operation thread the asp.net thread will go back to its own pool and will be ready to start serving a new request. With a default limit of 100 threads in a pool and given that your process is low-on-cpu-high-on-bandwidth I doub't you'll ever run out of pool threads before you run out of pipe space :). For more information on how to build async handler check this link (its an old article but valid non the less):
Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code

There is in fact a difference in threads in ASP .NET: Worker threads and IO threads (system threads which i believe you state as CLR thread).
Now ASP .NET use a worker thread on each request, unless custom configurations are used, and these worker threads are limited on your CPU number; this configuration can be set in IIS.
When you start an asynchronous task inside ASP.NET by using delegate for instance, you are using another worker thread. Delegates are a quick and dirty way of starting something asynchronous in .NET :)
If you want to start a new thread which does NOT use up a worker thread, then you must explicitly start a new thread like: new Thread()....etc. Now this comes with alot code management, and does not follow the event based asynchronous pattern.
However there is one way you can start asynchronous threads safely and that is by using .NETs own asynch methods on objects. Things you normally would use asynch for like SQL commands, webservice calls, etc. All these have a BEGIN and an END method.
By using these methods you will never use a worker thread, but an IO thread.
ASP .NET has a few tricks up its sleeve when it comes to asynchronous pages.
There are two alternatives:
Asynchronous page: which lets your page cycle to be asyncronous. This basicly means that the page is requested asynchronous.
Asynchronous page tasks: which lets you define tasks that will fire asynchronous when the page starts. Its kinda like Asynch threads, just that ASP .NET does alot of things for you, and its more restricted.
I dont have all the details, but please look into the two options on MSDN Library.
Here is an article on the subject: asynch programmin

Threadpool, order of execution and long running operations

I have a need to create multiple processing threads in a new application. Each thread has the possibility of being "long running". Can someone comment on the viability of the built in .net threadpool or some existing custom threadpool for use in my application?
Requirements :
Works well within a windows service. (queued work can be removed from the queue, currently running threads can be told to halt)
Ability to spin up multiple threads.
Work needs to be started in sequential order, but multiple threads can be processing in parallel.
Hung threads can be detected and killed.
EDIT:
Comments seem to be leading towards manual threading. Unfortunately I am held to 3.5 version of the framework. Threadpool was appealing because it would allow me to queue work up and threads created for me when resources were available. Is there a good 3.5 compatable pattern (producer/consumer perhaps) that would give me this aspect of threadpool without actually using the threadpool?

Your requirements essentially rule out the use of the .NET ThreadPool;
It generally should not be used for long-running threads, due to the danger of exhausting the pool.
It does work well in Windows services, though, and you can spin up multiple threads - limited automatically by the pool's limits.
You can not guarantee thread starting times with the thread pool; it may queue threads for execution when it has enough free ones, and it does not even guarantee they will be started in the sequence you submit them.
There are no easy ways to detect and kill running threads in the ThreadPool
So essentially, you will want to look outside the ThreadPool; I might recommend that perhaps you might need 'full' System.Threading.Thread instances just due to all of your requirements. As long as you handle concurrency issues (as you must with any threading mechanism), I don't find the Thread class to be all that difficult to manage myself, really.

Simple answer, but the Task class (Fx4) meets most of your requirements.
Cancellation is cooperative, ie your Task code has to check for it.
But detecting hung threads is difficult, that is a very high requirement anyway.
But I can also read your requirements as for a JobQueue, where the 'work' consists of mostly similar jobs. You could roll your own system that Consumes that queue and monitors execution on a few Threads.

I've done essentially the same thing with .Net 3.5 by creating my own thread manager:
Instantiate worker classes that know how long they've been running.
Create threads that run a worker method and add them to a Queue<Thread>.
A supervisor thread reads threads from the Queue and adds them to a Dictionary<int, Worker> as it launches them until it hits its maximum running threads. Add the thread as a property of the Worker instance.
As each worker finishes it invokes a callback method from the supervisor that passes back its ManagedThreadId.
The supervisor removes the thread from the Dictionary and launches another waiting thread.
Poll the Dictionary of running workers to see if any have timed out, or put timers in the workers that invoke a callback if they take too long.
Signal a long-running worker to quit, or abort its thread.
The supervisor invokes callbacks to your main thread to inform of progress, etc.