[Coefficient]

Alright, while freelancing and "mentoring" people C#, ive seen a lot of people asking me to help them multi thread their applications and what I often see is the stupid way of doing, using the System.Threading.Thread lib and it's quite awful! Developers should rather be using the System.Threading.Tasks lib as it's way more efficient alongside of being much easier to manage.

Let's start.

Here is a bad example of multithreading:

Code:

static void Main(string[] args)        {            Thread thread = new Thread(() =>            {                Console.WriteLine("This is a bad example of threading");            });        }

Now, while this still is asynchronous, it is considered obsolete by developers and microsoft.

Here is a good example of "multithreading" (note: this isn't necessarily multithreaded as it is mostly done asynchronously within the main thread/ task threadpool)

Code:

static void Main(string[] args)        {            Task task = Task.Factory.StartNew(() =>            {                Console.WriteLine("This is a good example of multithreading");            });        }

Alright that's it for now because im kinda tired but ill add more sometime if people are interested.

Also if you want to know more about efficient parallel, asynchronous programming just google:
c# asynchronous programming
c# parallels
c# tasks

and here are some links and videos I found useful:

Spoiler:

https://www.youtube.com/watch?v=RhLLxew4-TY

Basic understanding of a thread concept:
https://www.youtube.com/watch?v=mkkcqQlIpeQ

More onto tasks and asynchronous stuff:
https://www.youtube.com/watch?v=IONqMWGn9-w
https://www.youtube.com/watch?v=TRXFPPSM3zQ
https://www.youtube.com/watch?v=WjHhQYEBE_s


MSDN:
https://msdn.microsoft.com/en-us/library....110).aspx
https://msdn.microsoft.com/en-us/library/x13ttww7.aspx
https://msdn.microsoft.com/en-us/library/hh156513.aspx
https://msdn.microsoft.com/en-us/library/hh191443.aspx
https://msdn.microsoft.com/en-us/library/hh696703.aspx
https://msdn.microsoft.com/en-us/library/jj155756.aspx
https://msdn.microsoft.com/en-us/library....110).aspx
https://msdn.microsoft.com/en-us/library....110).aspx

I also recommend that you learn basic lambda before jumping into all of this because it makes this (and c# programming) must easier and faster.

[Killpot]

As much as I'd love to just take your word for task's being better, do you have any actual evidence to back it up? How are tasks and threads any different? I mean, you can do asynchronous stuff with threads, you can suspend, kill, and all other stuff. Like, you say it's "good" but fail to provide any reasoning as to why. I mean like, a thread represents an actual OS-level thread, with its own stack and kernel resources, and with that you have the highest degree of control; you can Abort() or Suspend() or Resume() a thread , you can observe its state, and you can set thread-level properties like the stack size, apartment state, or culture, whereas with tasks you can't Abort or Suspend or Resume, and tasks will only create a new thread if it meets certain criteria. I can understand it newcomers to coding will automatically flock to this, but I wouldn't say it's superior to threading if the threads are handled properly.

[Coefficient]

As much as I'd love to just take your word for task's being better, do you have any actual evidence to back it up? How are tasks and threads any different? I mean, you can do asynchronous stuff with threads, you can suspend, kill, and all other stuff. Like, you say it's "good" but fail to provide any reasoning as to why. I mean like, a thread represents an actual OS-level thread, with its own stack and kernel resources, and with that you have the highest degree of control; you can Abort() or Suspend() or Resume() a thread , you can observe its state, and you can set thread-level properties like the stack size, apartment state, or culture, whereas with tasks you can't Abort or Suspend or Resume, and tasks will only create a new thread if it meets certain criteria. I can understand it newcomers to coding will automatically flock to this, but I wouldn't say it's superior to threading if the threads are handled properly.

fuck my life i just made a 30 minute long well detailed post but chrome is autistic and reloaded the page when i pasted something in.

Ill still make a short resume though.

Ik this is straightforward but tasks are more efficient then threads because of several reasons, being better resource wise, somewhat more control (over customization).

 a thread represents an actual OS-level thread

Which is somewhat a disadvantage because if you plan on tasking 100 different threads to do 100 different actions, it's gonna take a lot resource wise. While tasks can be done on one thread asynchronously and can easily be modified to be parallel and thread-safe.

and tasks will only create a new thread if it meets certain criteria

TaskCreationOptions.LongRunning

I can understand it newcomers to coding will automatically flock to this, but I wouldn't say it's superior to threading if the threads are handled properly.

It is actually the opposite, threads are more oftenly used by beginners because it is a way simpler concept of understanding and basically an easier way of doing then tasks. Tasks being more funky and introducing the await and async keywords with more abstart concept make beginners stay away from it.

I also understand, yes you are somewhat right that threads can have more impact on the OS though tasks should rather be used from my point of view.

Here is a StackOverflow link that briefly explains the difference between tasks and thread
http://stackoverflow.com/questions/13429...ifferences

Some more quick links:
http://www.c-sharpcorner.com/blogs/task-...n-c-sharp1
http://blogs.msdn.com/b/pfxteam/archive/...03475.aspx

Anyways id like to explain some more but im done typing.

[Killpot]

As much as I'd love to just take your word for task's being better, do you have any actual evidence to back it up? How are tasks and threads any different? I mean, you can do asynchronous stuff with threads, you can suspend, kill, and all other stuff. Like, you say it's "good" but fail to provide any reasoning as to why. I mean like, a thread represents an actual OS-level thread, with its own stack and kernel resources, and with that you have the highest degree of control; you can Abort() or Suspend() or Resume() a thread , you can observe its state, and you can set thread-level properties like the stack size, apartment state, or culture, whereas with tasks you can't Abort or Suspend or Resume, and tasks will only create a new thread if it meets certain criteria. I can understand it newcomers to coding will automatically flock to this, but I wouldn't say it's superior to threading if the threads are handled properly.

fuck my life i just made a 30 minute long well detailed post but chrome is autistic and reloaded the page when i pasted something in.

Ill still make a short resume though.

Ik this is straightforward but tasks are more efficient then threads because of several reasons, being better resource wise, somewhat more control (over customization).

 a thread represents an actual OS-level thread

Which is somewhat a disadvantage because if you plan on tasking 100 different threads to do 100 different actions, it's gonna take a lot resource wise. While tasks can be done on one thread asynchronously and can easily be modified to be parallel and thread-safe.

and tasks will only create a new thread if it meets certain criteria

TaskCreationOptions.LongRunning

I can understand it newcomers to coding will automatically flock to this, but I wouldn't say it's superior to threading if the threads are handled properly.

It is actually the opposite, threads are more oftenly used by beginners because it is a way simpler concept of understanding and basically an easier way of doing then tasks. Tasks being more funky and introducing the await and async keywords with more abstart concept make beginners stay away from it.

I also understand, yes you are somewhat right that threads can have more impact on the OS though tasks should rather be used from my point of view.

Here is a StackOverflow link that briefly explains the difference between tasks and thread
http://stackoverflow.com/questions/13429...ifferences

Some more quick links:
http://www.c-sharpcorner.com/blogs/task-...n-c-sharp1
http://blogs.msdn.com/b/pfxteam/archive/...03475.aspx

Anyways id like to explain some more but im done typing.

That feel I know all too well, I've had it happen to me more times than I like to admit, now I just cautiously Ctr-A + C every couple of seconds while posting...

[Coefficient]

fuck my life i just made a 30 minute long well detailed post but chrome is autistic and reloaded the page when i pasted something in.

Ill still make a short resume though.

Ik this is straightforward but tasks are more efficient then threads because of several reasons, being better resource wise, somewhat more control (over customization).
Which is somewhat a disadvantage because if you plan on tasking 100 different threads to do 100 different actions, it's gonna take a lot resource wise. While tasks can be done on one thread asynchronously and can easily be modified to be parallel and thread-safe.

TaskCreationOptions.LongRunning

It is actually the opposite, threads are more oftenly used by beginners because it is a way simpler concept of understanding and basically an easier way of doing then tasks. Tasks being more funky and introducing the await and async keywords with more abstart concept make beginners stay away from it.

I also understand, yes you are somewhat right that threads can have more impact on the OS though tasks should rather be used from my point of view.

Here is a StackOverflow link that briefly explains the difference between tasks and thread
http://stackoverflow.com/questions/13429...ifferences

Some more quick links:
http://www.c-sharpcorner.com/blogs/task-...n-c-sharp1
http://blogs.msdn.com/b/pfxteam/archive/...03475.aspx

Anyways id like to explain some more but im done typing.

That feel I know all too well, I've had it happen to me more times than I like to admit, now I just cautiously Ctr-A + C every couple of seconds while posting...

Now now you've gotten grumpy here  :tehe:

[0xDEAD10CC]

As much as I'd love to just take your word for task's being better, do you have any actual evidence to back it up? How are tasks and threads any different? I mean, you can do asynchronous stuff with threads, you can suspend, kill, and all other stuff. Like, you say it's "good" but fail to provide any reasoning as to why. I mean like, a thread represents an actual OS-level thread, with its own stack and kernel resources, and with that you have the highest degree of control; you can Abort() or Suspend() or Resume() a thread , you can observe its state, and you can set thread-level properties like the stack size, apartment state, or culture, whereas with tasks you can't Abort or Suspend or Resume, and tasks will only create a new thread if it meets certain criteria. I can understand it newcomers to coding will automatically flock to this, but I wouldn't say it's superior to threading if the threads are handled properly.

A task will organize code into a threadpool if certain criteria is met, or dictate that a certain thread is enough, but in addition to it being much more maintainable, it's also much more easily interfacable and supports the new async/await paradigm as well whereas threads by themselves do not. Chances are unless you are a master in the art of using raw threads, the TPL library will do a better job than you about it. If you need to guarantee that a thread is created then you would probably just create and start a new thread, but as for any reason why this is a specific requirement would be beyond me in 99% of programming specific scenarios.

Based on the way I see people using threads too and the way they join threads, I think that's enough support showing why Task is a much more feasible option... LOL.

Alright, while freelancing and "mentoring" people C#, ive seen a lot of people asking me to help them multi thread their applications and what I often see is the stupid way of doing, using the System.Threading.Thread lib and it's quite awful! Developers should rather be using the System.Threading.Tasks lib as it's way more efficient alongside of being much easier to manage.

Let's start.

Here is a bad example of multithreading:

Code:

static void Main(string[] args)        {            Thread thread = new Thread(() =>            {                Console.WriteLine("This is a bad example of threading");            });        }

Now, while this still is asynchronous, it is considered obsolete by developers and microsoft.

Here is a good example of "multithreading" (note: this isn't necessarily multithreaded as it is mostly done asynchronously within the main thread/ task threadpool)

Code:

static void Main(string[] args)        {            Task task = Task.Factory.StartNew(() =>            {                Console.WriteLine("This is a good example of multithreading");            });        }

Alright that's it for now because im kinda tired but ill add more sometime if people are interested.

Also if you want to know more about efficient parallel, asynchronous programming just google:
c# asynchronous programming
c# parallels
c# tasks

and here are some links and videos I found useful:

Spoiler:

https://www.youtube.com/watch?v=RhLLxew4-TY

Basic understanding of a thread concept:
https://www.youtube.com/watch?v=mkkcqQlIpeQ

More onto tasks and asynchronous stuff:
https://www.youtube.com/watch?v=IONqMWGn9-w
https://www.youtube.com/watch?v=TRXFPPSM3zQ
https://www.youtube.com/watch?v=WjHhQYEBE_s


MSDN:
https://msdn.microsoft.com/en-us/library....110).aspx
https://msdn.microsoft.com/en-us/library/x13ttww7.aspx
https://msdn.microsoft.com/en-us/library/hh156513.aspx
https://msdn.microsoft.com/en-us/library/hh191443.aspx
https://msdn.microsoft.com/en-us/library/hh696703.aspx
https://msdn.microsoft.com/en-us/library/jj155756.aspx
https://msdn.microsoft.com/en-us/library....110).aspx
https://msdn.microsoft.com/en-us/library....110).aspx

I also recommend that you learn basic lambda before jumping into all of this because it makes this (and c# programming) must easier and faster.

Task.Factory.StartNew() is not the preferred way to create a generic Task. Task.Run() is -- when you're just invoking a lambda like in your example (since Task.Run() is a call to StartNew() in the background with specific arguments), but it's main purpose is to aid the usage of async and piping CPU work to ThreadPool.

[Wildfire]

I've been doing C# for a number of years, and I've never actually used tasks, always either background workers or plain old threads. Interesting information, honestly, I feel like a dipshit for not really knowing of this earlier. So if I understand this correctly, tasks are just an easier way to do threading without the big amount of hassle?

[0xDEAD10CC]

Easier, less error prone, more than likely more optimized in many cases unless you've spent a considerable amount of time perfecting your exact threading approach -- you should hardly ever need to explicitly create your own thread in modern C#. Additionally, Tasks have a certain set of rules that determine what thread to run code on separately, or whether it belongs within a threadpool, and states that you'll get a result sometime in the future. It's also trivial for async/await support in C# 5.