4

I've read about advantages of Tasks Difference between Task (System.Threading.Task) and Thread

Also msdn says that "...in the .NET Framework 4, tasks are the preferred API for writing multi-threaded, asynchronous, and parallel code."

Now my program contains such code which receive multicast data from udp:

thread = new Thread(WhileTrueFunctionToReceiveDataFromUdp);
.....
thread.Start();

I have several such threads for each socket. Am I better to replace this code to use Task?

Community
  • 1
  • 1
Oleg Vazhnev
  • 23,239
  • 54
  • 171
  • 305
  • One thread for each socket is usually bad enough. Many threads per socket are not a step in the right direction, and using the thread pool instead of your own threads could be even worse. – Jon Mar 15 '12 at 20:21
  • 2
    Of course not. Never replace code that works. Especially threaded code. Task does not alter the behavior of threads, it just makes writing such code easier. – Hans Passant Mar 15 '12 at 20:22
  • @Jon what should I use to receive data from several sockets then? – Oleg Vazhnev Mar 15 '12 at 20:29
  • @javapowered: I don't have hands-on Java experience, but there are facilities in most C-alikes for e.g. waiting on a number of objects (in this case sockets) at the same time. When the wait is complete, you are told which object caused it to complete. This scheme can service many sockets from one thread. – Jon Mar 15 '12 at 20:37

2 Answers2

2

It depends on what you're doing - if you're not going to use any of the new features in Task and the TPL, and your existing code works, there's no reason to change.

However, Task has many advantages - especially for operations that you want to run in a thread pool thread and return a result.

Also - given that you're using "threads for each socket", you likely will have longer life threads. As such, if you do switch to Task.Factory.StartNew, you'll potentially want to specify that the tasks should be LongRunning or you'll wind up using a lot of ThreadPool threads for your socket data (with the default scheduler).

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • and there are no reason to keep Threads taking into account that I anyway changing this code now? `Tasks` should be faster.... – Oleg Vazhnev Mar 15 '12 at 20:22
  • @javapowered: `Tasks` are not faster, but have clever schedule mechanism built in in `.NET Framework`. Which **can** make them faster. – Tigran Mar 15 '12 at 20:28
  • @javapowered They won't be any faster - it's just a nicer programming model. Under the hood, they use ThreadPool threads (or normal threads, with LongRunning specified) – Reed Copsey Mar 15 '12 at 20:30
1

Do not change anything in the code that already works and will work (at least according to Microsoft). Change it only for reasons like :

  • You want to use a new features offered by Tasks

  • Personal study.

Remember that on OS level they basically end up into the same OS Kernel objects.

Hope this helps.

Tigran
  • 61,654
  • 8
  • 86
  • 123
  • @javapowered: so if the reason is actually presence of `Thread` type objects, change it to `Tasks`. Cause as you already read it I think form the link provided by yourself, they more clever concurrency management taking in account CPU on host machine. – Tigran Mar 15 '12 at 20:27