Develop Reference

c# .Net 4.5 Communication between threads

I am building an application where it is possible to monitor some MCU hardware (sensors readings etc) in real time. For the communication I am using a CAN bus.
Basically i have 2 threads as of now. One is the main thread where the GUI is running and the other is managing/monitoring the communication between the device. So the obvious thing is that i need to pass the data from the communications thread to the gui thread. However what should be the right way to do it? I know how to pass a data back to the calling thread when the child thread has finished working, but in this case the communications thread is running all the time.
Of course the communications logic is represented by a separate class (CANManager).
I have couple of ideas of my own, however I would like to know what is the "right" way how this should be done.
Thanks in advance :)

Generally in any programming language you need to consider a pub-sub architecture for communicating across threads. This means that for each thread A which wishes to send a message to thread B, you should post a 'message' or event from that thread onto a queue, to be consumed by another thread when it is free. If you just google 'Cross Thread communication c#' you will find numerous articles to read over.
Specifically, in .NET the way to invoke a method or delegate on another (any) thread is to use SynchronizationContext. This is common to both Windows Forms and WPF, whereas WPF has a Dispatcher which is distinct to this framework to invoke on the UI thread only.
There are many frameworks, libraries, patterns available to do this sort of technique. One of them is the Task Parallel Library. TPL allows you to create a Task, or Task and invoke it on a threadpool, UI, same or specific thread. TPL allows thread marshalling via the use of Schedulers. You can use the built-in Schedulers or create your own. Schedulers use SynchronizationContext at their heart to do the thread marshalling.
One particularly interesting pattern of TPL is the ability to run a delegate on one thread and then chain multiple operations on other threads, e.g. on completion or on error. I would look into the Task Asynchronous Pattern and consider returning Task from async methods so you can chain on them using ContinueWith.

Difference between Task (System.Threading.Task) and Thread

From what I understand about the difference between Task & Thread is that task happened in the thread-pool while the thread is something that I need to managed by myself .. ( and that task can be cancel and return to the thread-pool in the end of his mission )
But in some blog I read that if the operating system need to create task and create thread => it will be easier to create ( and destroy ) task.
Someone can explain please why creating task is simple that thread ?
( or maybe I missing something here ... )

I think that what you are talking about when you say Task is a System.Threading.Task. If that's the case then you can think about it this way:
A program can have many threads, but a processor core can only run one Thread at a time.
Threads are very expensive, and switching between the threads that are running is also very expensive.
So... Having thousands of threads doing stuff is inefficient. Imagine if your teacher gave you 10,000 tasks to do. You'd spend so much time cycling between them that you'd never get anything done. The same thing can happen to the CPU if you start too many threads.
To get around this, the .NET framework allows you to create Tasks. Tasks are a bit of work bundled up into an object, and they allow you to do interesting things like capture the output of that work and chain pieces of work together (first go to the store, then buy a magazine).
Tasks are scheduled on a pool of threads. The specific number of threads depends on the scheduler used, but the default scheduler tries to pick a number of threads that is optimal for the number of CPU cores that you have and how much time your tasks are spending actually using CPU time. If you want to, you can even write your own scheduler that does something specific like making sure that all Tasks for that scheduler always operate on a single thread.
So think of Tasks as items in your to-do list. You might be able to do 5 things at once, but if your boss gives you 10000, they will pile up in your inbox until the first 5 that you are doing get done. The difference between Tasks and the ThreadPool is that Tasks (as I mentioned earlier) give you better control over the relationship between different items of work (imagine to-do items with multiple instructions stapled together), whereas the ThreadPool just allows you to queue up a bunch of individual, single-stage items (Functions).

You are hearing two different notions of task. The first is the notion of a job, and the second is the notion of a process.
A long time ago (in computer terms), there were no threads. Each running instance of a program was called a process, since it simply performed one step after another after another until it exited. This matches the intuitive idea of a process as a series of steps, like that of a factory assembly line. The operating system manages the process abstraction.
Then, developers began to add multiple assembly lines to the factories. Now a program could do more than one thing at once, and either a library or (more commonly today) the operating system would manage the scheduling of the steps within each thread. A thread is kind of a lightweight process, but a thread belongs to a process, and all the threads in a process share memory. On the other hand, multiple processes can't mess with each others' memory. So, the multiple threads in your web server can each access the same information about the connection, but Word can't access Excel's in-memory data structures because Word and Excel are running as separate processes. The idea of a process as a series of steps doesn't really match the model of a process with threads, so some people took to calling the "abstraction formerly known as a process" a task. This is the second definition of task that you saw in the blog post. Note that plenty of people still use the word process to mean this thing.
Well, as threads became more commmon, developers added even more abstractions over top of them to make them easier to use. This led to the rise of the thread pool, which is a library-managed "pool" of threads. You pass the library a job, and the library picks a thread and runs the job on that thread. The .NET framework has a thread pool implementation, and the first time you heard about a "task" the documentation really meant a job that you pass to the thread pool.
So in a sense, both the documentation and the blog post are right. The overloading of the term task is the unfortunate source of confusion.

Threads have been a part of .Net from v1.0, Tasks were introduced in the Task Parallel Library TPL which was released in .Net 4.0.
You can consider a Task as a more sophisticated version of a Thread. They are very easy to use and have a lot of advantages over Threads as follows:
You can create return types to Tasks as if they are functions.
You can the "ContinueWith" method, which will wait for the previous task and then start the execution. (Abstracting wait)
Abstracts Locks which should be avoided as per guidlines of my company.
You can use Task.WaitAll and pass an array of tasks so you can wait till all tasks are complete.
You can attach task to the parent task, thus you can decide whether the parent or the child will exist first.
You can achieve data parallelism with LINQ queries.
You can create parallel for and foreach loops
Very easy to handle exceptions with tasks.
*Most important thing is if the same code is run on single core machine it will just act as a single process without any overhead of threads.
Disadvantage of tasks over threads:
You need .Net 4.0
Newcomers who have learned operating systems can understand threads better.
New to the framework so not much assistance available.
Some tips:-
Always use Task.Factory.StartNew method which is semantically perfect and standard.
Take a look at Task Parallel Libray for more information
http://msdn.microsoft.com/en-us/library/dd460717.aspx

Expanding on the comment by Eric Lippert:
Threads are a way that allows your application to do several things in parallel. For example, your application might have one thread that processes the events from the user, like button clicks, and another thread that performs some long computation. This way, you can do two different things “at the same time”. If you didn't do that, the user wouldn't be to click buttons until the computation finished. So, Thread is something that can execute some code you wrote.
Task, on the other hand represents an abstract notion of some job. That job can have a result, and you can wait until the job finishes (by calling Wait()) or say that you want to do something after the job finishes (by calling ContinueWith()).
The most common job that you want to represent is to perform some computation in parallel with the current code. And Task offers you a simple way to do that. How and when the code actually runs is defined by TaskScheduler. The default one uses a ThreadPool: a set of threads that can run any code. This is done because creating and switching threads in inefficient.
But Task doesn't have to be directly associated with some code. You can use TaskCompletionSource to create a Task and then set its result whenever you want. For example, you could create a Task and mark it as completed when the user clicks a button. Some other code could wait on that Task and while it's waiting, there is no code executing for that Task.
If you want to know when to use Task and when to use Thread: Task is simpler to use and more efficient that creating your own Threads. But sometimes, you need more control than what is offered by Task. In those cases, it makese sense to use Thread directly.

Tasks really are just a wrapper for the boilerplate code of spinning up threads manually. At the root, there is no difference. Tasks just make the management of threads easier, as well as they are generally more expressive due to the lessening of the boilerplate noise.

How can I use threads to run database queries in XNA?

I'm currently developing a project with XNA that is pulling information (ID, name, file location, etc) about each of my objects (each object will be displayed on screen) from a local SQL database.
I'd like to run my database queries on a separate thread so the rendered screen doesn't freeze if the database hangs or some other unforeseen event occurs. I'm using XNA 4.0 and the application will only be running on windows. Is this possible, and if so, how?

There are a number of options available. Generally speaking you need the query to run in a separate thread. You can use
Thread pool
QueueUserWorkItem
Tasks
Background worker
Async calls to the database
Parallel invoke
Manually created threads here and here
I would start with thread pooling and see how that works, dedicated manual threads are not that robust in terms of memory management and reuse.

Not to do it at all. Seriously. There are good reasons for using threads, but your reasons are bogus:
the rendered screen doesn't freeze if the database hangs or some other unforeseen event occur
Databases dont hang and unforseen events are unforseen events. How you can cope with the database not answering for 3 minutes, for example? Show a screen with objects that are unknown?

How do you mean "best"? There are a lot of ways to use threads and they all have strengths and weaknesses.
Declaring a new thread explicitly and starting it gives you the most direct control over the execution state of that thread:
var myDbThread = new Thread(()=>myDbRepo.GetRecordById<MyEntity>(idString));
myDbThread.Start();
Now, as long as you have a reference to myDbThread, you can abort it, pause it, join on it, etc. BUT, with control comes responsibility; you have to manage the threads you create yourself.
For most parallel tasks, using the ThreadPool is recommended. However, you lose some of the control:
Action myDbLambda = () => myEntityProperty = myDbRepo.GetRecordById<MyEntity>(idString);
var asyncResult = myDbLambda.BeginInvoke();
Once asyncResult.IsComplete returns true, myEntityProperty has the value. You can also architect it as a Func, and use a callback to set the value (this is recommended). The Asynchronous Model is built in to the BeginInvoke()/EndInvoke() method pair, and many exceptions like timeouts are expected by the ThreadPool, which will simply restart the timed-out thread. However, you can't "give up" and terminate a ThreadPool thread, "joining" on a ThreadPool thread is a little trickier, and if you're launching a lot of threads, the ThreadPool will start them in 250ms intervals which may not be the best use of processor.
There are many ways to use the ThreadPool; before delegates became even more important to .NET programming in v3.5, ThreadPool.QueueUserWorkItem was the main method. Now, as I said, delegates have BeginInvoke and EndInvoke methods allowing you to kick off background processes with the asynchronous model built in behind the scenes. In WinForms/WPF, you can also create BackgroundWorker components which are event-driven, allowing you to monitor progress and completion in a GUI element.
One thing to be aware of; it is virtually never a good idea to use background threads in ASP.NET. Unless you really know what you're doing, best-case you won't get the results of the behavior you sent to the worker thread, and worst-case you can crash your site trying.

C#: "not responding" window when program is doing some background processing

In my C# project I have a form that is displayed which shows a progress bar.
Some processing is then done which involves communication over the internet.
While this processing is occurring the form says "Not Responding" when run in Win 7, in XP the form just goes white.
Either way, it is not acceptable.
Do I need to use threads to solve this problem?
What are some of the basics of threads that I would need to use in this scenario?

Your processing must be done within a thread.
Out of your thread you have to invoke your progress bar to show the progress.
progressBar1.Invoke((MethodInvoker)delegate
{
progressBar1.Value = (int)((i / limit) * 100);
});

Yes you have to use threads to keep your UI responsive while something gets done in background. But this question cannot be just answered just like "use Threads to solve it", because there are a lot of forms in which you could use threads. (Backgroundworker, Threadpool, Asynch IO, Creating a Thread, Task Parallel Library, CCR, and a lot more you could imagine for every kind of parallelization scenarios).
As you said you are doing some processing which needs connecting to internet. Where does the most amount of time spent? is it IO over network which takes most time in that case probably Asynchronous IO makes a lot of sense. If time spent is in one huge processing operation then Background worker is perfect, but if this processing can be further broken down into smaller chunks of parallel processing tasks then TPL or ThreadPool is preferred. Till now I am talking only about some processing which happens on Windows forms event, and keep the UI responsive. But based on the scenario there are numerous other options you could use to make threading work for you.
Asynch IO doesnt look like you are doing threading but it more matches with eventing model of winforms. So you could look at that if you are very comfortable with event based programming.
Threadpool looks more like a queue of workers to which you could keep throwing all the work needs to be done, and the framework figures out how many threads to run based on the kind of machine you are using (dual core, quad core etc) and it would get your work items doen in optimal way.
Bottom line its not one answer to use one over other, instead based on the kind of problem you are solving threading model needs to be decided on.

A cheaper option is to add the line Application.DoEvents() inside whatever loops your app is running, which will cause it to process messages each time it gets there.

If you use System.Net.WebClient, you can use DownloadDataAsync() to communicate in a non blocking way.
The System.Net.Sockets.Socket class proviede non blocking communication, too.
Sockets example
WebClient example

Yes, better way is use BackGroundWorker component. It is wrapper over threads, so you don't need to manage threads. You can get more info from Background worker on MSDN

As long as the program remain in the function to process something, the UI will not update. That is why you may need to start a background thread, so that your UI can continue functioning while your background thread can do the work. An alternatively is to use asynchronous functions.
example of background thread

From your description I'll assume that all your work is currently being done on a single thread, the main thread which is also used for your GUI.
The progress bar can only update when that main thread gets a chance to check its state and apply any expected changes.
Therefore it is important that your processing work does not occupy the main thread for extended periods of time.
There are two main approaches to handling this:
Stepping the processing activity.
Break down the processing step into a number of serial tasks - each short in nature.
Progressively call each of these serial tasks in the OnIdle event on your main thread.
Using a background thread.
See other answers giving more detail on how this would work.
The stepping approach can be useful if you want to avoid the sublties of thread synchronisation. The threading approach is probably better but only essential if it is impossible to guarantee serial short steps.

Threads and the new Task library in C#

I came across this comprehensive explanation of the new .NET TPL library recently, and it sounded pretty impressive. Having read the article, it appears that the new taskmanager is so clever it can even tell whether your parallel tasks would be faster if done serially on the same thread, rather than be parcelled out to worker threads. This could often be a difficult decision.
Having written a lot of code using what threading was available previously, it now seems as though everything ought to be written with tasks, which would hand over a lot of the work to the taskmanager.
Am I right in thinking that whatever I previously did with threads should now be done with tasks? Of course there will always be cases where you need fine control, but should one generally throw ordinary background work onto a task, rather than a new thread? Ie has the default "I need this to run in the background => new thread" become "new task" instead?

Basically, yes, you want to use tasks and let them take care of the thread use. In practice, the tasks are processed by a thread pool.

Tasks are managed by the TaskScheduler. The default TaskScheduler runs tasks on ThreadPool threads and as such you have the same issues as you normally would when using the ThreadPool: It is hard to control the setup (priority, locale, background/foreground, etc.) on threads in the pool. If you need to control any of these aspects it may be better to manage the threads yourself. You may also implement your own scheduler to handle some of these issues.
For most other parts the new Task class works very well.