Why are we including `System.Threading.Thread` in .NET Standard? about standard HOT 23 CLOSED

While most .NET applications don't necessarily use raw threads in their own code, all of the built-in concurrency abstractions (including Tasks) depend on the low level threading primitives, and they're very useful for library authors, for libraries such as Akka.NET and Hopac. Raw threads, semaphores and mutexes will never be obsolete; they are essential for low level and high performance tasks.

from standard.

As others said, it's not an either-or. We can have Task and also have Thread. Yes, for the most part, developers shouldn't manage their own threads but rely on Task or thread pooling but that doesn't mean we shouldn't expose the type. First of all, compat isn't a nice to have. For a platform that's 15 years old it's critical because otherwise you're cutting of your customer base. Secondly, we've tried that experiment of not exposing Thread before. It just doesn't work:

1. Moving existing code from threads to tasks and thread pools is non-trivial amount of work with dubious value. Not taking a dependency on it is a value-add, but removing it from existing code is often just introducing a ton of bugs in an area that is super hard to debug.
2. The folks that need threads really, really need thread control.

from standard.

There is some relevant discussion here.

Aside from that, it's the same reason we are bringing anything back into the standard: compatibility. Even if there were NO reason to ever use threads anymore, we would still add them back. Lots of things are going to be in the standard that you should realistically never use when writing new code. And anyways, there are still good reasons to use them in some scenarios, so it's much better than other (obsolete) things in the standard.

from standard.

While most .NET applications don't necessarily use raw threads in their own code, all of the built-in concurrency abstractions (including Tasks) depend on the low level threading primitives

Just because threads are there for lower level concepts doesn't mean it should be exposed to the user, or guaranteed to be there.

Raw threads, semaphores and mutexes will never be obsolete; they are essential for low level and high performance tasks.

I'm not arguing they should be removed from .NET Core or the framework, just that that having them in .NET Standard makes no sense since .NET Threads (not threads but System.Threading.Thread) are very windows specific in some ways and don't make sense in modern programing ideas.

I'm more in favor of bringing Tasks forward so that they can do what we fallback to System.Threading.Threads for.

from standard.

It's simple:

• .NET Standard 2.0 will have Thread
• .NET Standard 1.3 doesn't really support Thread; the package doesn't provide an implementation for all platforms.

(Our package authoring is complicated. In a nutshell, supporting means a package has to provide a compile time artifact and a deployment artifact. The good old lib folder did both, but we had to expand that for us in order to provide diffferent implementations based on OS, architecture, and TFM.)

With respect to UWP:

• UWP currently only supports .NET Standard 1.4
• Our goal is to eventually extend UWP to also implement .NET Standard 2.0. Once that happens, UWP will also support Thread.

Does this help?

from standard.

There are very few times developers should be using raw .NET threads anymore so why include them?

Threads are fine. Most standard libraries on out there on other platforms let you make threads (yes real threads not just green threads).

from standard.

For the past few months I have been eliminating partitions in my code libraries that were necessary because of the peculiar restrictions on portable libraries. I intend to eventually make all my code make use of Async and await but I really do not want to do all of that at the same time.

Being able to move the library from Framework to Standard without having to kill the use of threads at the same time is a lot easier. Much of this code is work that was done before the await approach was in C#.

from standard.

Thread is indeed in Net Standard 2.0 as you see in this repo. The next full release of .NET Core will support Net Standard 2.0 and thus Thread. UWP does not yet support it but some work has begun

from standard.

@Noemata There are some scenario do need Thread , for example : long running background tasks, It's not worth to take a threadPool thread ( System.Threading.Tasks.Task) , because ThreadPool have limited threads.
But I understand your pain : Microsoft keep add new feature to the OS and .Net , but It not only fouce developer to update thire dev environment, but also fouce every OS user to update, otherwise the app won't work.
And on other hand javascript allow you to if(xxx){ use that } else { simulation one and use or disable this feature }

from standard.

.NET Threads (not threads but System.Threading.Thread) are very windows specific in some ways and don't make sense in modern programing ideas.

This is true for a lot of the things in the BCL, especially system- and OS-level types like this. It's a natural consequence of the whole thing being designed for Windows originally.

I'm more in favor of bringing Tasks forward so that they can do what we fallback to System.Threading.Threads for.

Those are here, too.

from standard.

So just to be clear this means that we are not including it right? Which means that there is no access to System.Threading.Thread from a UWP app?

from standard.

Ok, thank you. That is great news to me. I couldn't find any info anywhere else on whether it was being supported or not. Can we expect the next release of .NET Core to be Q1 2017?

from standard.

Thread does not appear in UWP simply by having it in .NET Core -- after all we already shipped it in .NET Core. We have to update the framework available to UWP. Unfortunately I do not think we shared a release date for that. @terrajobst what is there to say there?

from standard.

This thread left me somewhat confused regarding the availability of Thread in UWP: looking at System.Threading.Thread, it does seem to support netstandard13. If you're saying Thread isn't available in UWP, does that mean UWP doesn't support netstandard13, or am I mixing things up?

from standard.

Thanks for the clarification @terrajobst.

It's definitely confusing for System.Threading.Thread to support netstandard13 (in the sense that it's listed in https://www.nuget.org/packages/System.Threading.Thread/), but at the same time for netstandard13 to not really support Thread... I guess this also mean it's possible to successfully build a UWP app with a dependency on Thread, only to have it bomb at runtime, which is unfortunate.

Thanks for your time, I'll look into workarounds until netstandard20 is fully supported.

from standard.

I guess this also mean it's possible to successfully build a UWP app with a dependency on Thread, only to have it bomb at runtime, which is unfortunate.

I don't think that's true; I believe you get a package restore failure.

from standard.

I guess this also mean it's possible to successfully build a UWP app with a dependency on Thread, only to have it bomb at runtime, which is unfortunate.
I don't think that's true; I believe you get a package restore failure.Apologies, I

Apologies, I wrote that based on a user report without actually checking. Thanks for all the answers.

from standard.

Thread still have a good use case: thread pooling everything may end up to unpredictable behavior in some cases like when communicating with another process.

For example, create a Process that consumes STDIN and produce something to STDOUT. If you use tasks to feed STDIN and another task to consume STDOUT. Given that you create a bunch of these monitored processes, you'll end up depleting the threadpool (tasks) to feed the external process or to consume its output. The STDIN will either starve or the STDOUT gonna block when its buffer is full because not task is available to consume it.

That process.WaitForExit(2000) you set to block the current thread during the external process execution will time up, then you'll kill the process and assumes it failed even if it was just starving/blocked.

I think it is important to have threads outside of a thread pool context for IO monitoring/feeding and waiting for something else to complete. These are thread that are doing nothing 99.9% of the time and shall not be accounted for since they won't clutter the processor. They will consume some memory but from there, its is not a programming issue anymore.

That is a real life issue I struggled with a few months ago by using Tasks wall-to-wall and I fixed it by using non-pooled, good old threads. I think that increasing the ThreadPool MaxPoolSize is just an inconvenient patch that pushes the problem to a later time.

from standard.

This is yet another example of a promise half kept by Microsoft that ends up breaking the backs of developers metaphorically. When emphatic reasoned calls for resolution are ignored, we conclude Microsoft is playing a game we will never understand and will never include us. Curiously, without developers eventually the game stops. Why aren't there more apps in the Microsoft store? The untold story; it's because devs try to build something that should work, then fail because of hidden pitfalls such as this. Eventually we move on to other things. And that's not a good thing. Backport System.Threading.Thread to every release of Windows 10 so far. It's that important!!!

from standard.

@Noemata

I really don't understand what decision you're disagreeing with or what we did wrong. Could you elaborate?

from standard.

The basic issue is the fact that adamant cries for help or attention on what later become obviously significant issues are ignored by Microsoft at critical stages of product release cycles. And we all get harmed as a result, Microsoft and the developers that wish to work with Microsoft tech both suffer.

Here's one really good example: when Windows 8 was released there was no Developer Mode. Devs were screaming for the feature, yet Microsoft chose to implement a convoluted strategy for sideloading that required special licensing and the ability to purchase "special" keys from an enterprise level sales channel approved by Microsoft. We would all agree that it's just plain silly not to have a Developer Mode at this point.

Likewise, having System.Threading.Thread fail at runtime (no less) on .Net Standard 1.4 and below when building a UWP app that needs this is, to put it bluntly, nuts. Occasionally, certain API's acquire a religious level of adoption. Despite Microsoft's new found religions and its perceived need to purge us of our evil ways, pushing the reboot button is simply too disruptive. Having Capabilities tied to user controlled policies is a good compromise that would allow a user to tame an app they perceived as being problematic. Taking System.Threading.Thread away to remove potential battery drain issue is just dumb. As dumb as not having a Developer Mode.

So now it's back in .Net Standard 2.0. So what, is the correct response, because we have millions of Windows 10 systems that will not be upgrading to the latest OS release any time soon if ever. Not having System.Threading.Thread fragments .Net Standard on earlier releases/system installs. Please, just fix this gaping whole so we can get older systems working with a significantly larger set of libs. Microsoft is, in a less metaphorical sense, shooting itself and its developers in the foot by not fixing such problems. Do the statistical profiling you've been claiming to do. System.Threading.Thread is used by a large number of critical libs.

Lastly, the shiny new toy must always be more than, not a subset of the last shiny new toy. Else it looks like we keep going backwards.

from standard.

So it's not all dreary negativity I'd like to add that the work and direction of .Net Standard 2.x is fantastic. Please spread some of that love backwards.

from standard.

I consider @terrajobst to be a really decent fellow and to have the best interest of the .Net community at heart. However, it is frustrating to see a Microsoft internal expert of this calibre state: "I don't think that's true; I believe you get a package restore failure." This is precisely what does happen, your app fails at runtime. The package restore failure would have saved us a lot of grief and would have been the correct behavior.

Given that System.Threading.Thread is now available in .Net Standard 2.0, whatever OS modifications were made to make it available, these same modifications should be back ported so that the original promise is kept. Microsoft needs to realize that API reboots are a huge problem for the platform as are unkept promises (broken APIs). API's should work consistently across releases and should be there if we can link against them. The HoloLens now has a host of API's that don't behave correctly because of the differences associated with the HoloLens shell. Either make those APIs work, or take them away. Forcing devs to discover what's broken and what works is a weird way to do business of you're in the OS business. It's a fantastic way to seed distrust.

from standard.