Thread.Yield() in coreclr

Question

In .NET Thread class has static method Yield.
I see that method in coreclr implementation of Thread.
But documentation doesn't contain that Method description.
Also .NET CLI (dotnet build) cant compile code with that method invocation.
Why?

upd
runtime: 1.0.0-rc1-update1 coreclr x64 darwin

project.json

{
    "version": "1.0.0-*",
    "compilationOptions":
    {
        "emitEntryPoint": true
    },
    "dependencies":
    {
        "NETStandard.Library": "1.0.0-rc2-*",
        "System.Threading": "4.0.11-rc3-*"
    },

    "frameworks": {
        "dnxcore50": {}
    }
}

upd2
I'm not going to use Thread.Yield();
I was just wondering why some framework features are absent in coreclr.

Bloodshot

It depend on wich framework, wich platform, how your project is configured. Can you provide the code sample and project.json you used ? – Cytologist

I'm going to side-track a bit - why do you think you need to use Thread.Yield? I'm pretty sure there's a better way to do whatever you're doing than using Thread.Yield, especially when you're targeting coreCLR. – Araarab

Fabien, i've edited the question – Bloodshot

Luaan, I've just noticed that when press ctrl+space after Thread. I've not gonna use it. But also, I can't find Process class and I suppose that answer on this question helps me understand why. – Bloodshot

Answer 1

You are looking at the wrong file, the correct one is in the corefx depository. This one.

Note that it is special, it only contains declarations. It is the reference assembly, the one that your compiler uses. As you can tell, it does not have a Yield() method so a guaranteed eek! from the compiler. Distinguishing the reference assembly from the implementation assembly in the GAC is something that happened a long time ago, have a look-see at the C:\Program Files (x86)\Reference Assemblies directory on a Windows machine.

The exact reasons that a member or type is omitted is not always obvious. From what I've seen, factors that play a role are:

1. The type or member is simply not supported by the .NETCore version of the CLR. Originally designed to be a small version of the CLR that was targeted to mobile devices and easy to download, Silverlight is the most recognizable member of that family. With the additional feature that small also makes it easier to port the CLR to another platform, .NETCore served as the bootstrap of CoreCLR since making it run on Linux and OSX was a strong goal. AppDomain is a good example.

2. It might not yet have been implemented on every OS or it is in the wrong .NETStandard profile. Keeping it out of the reference assembly is a very simple way to prevent a program from accidentally using it and trigger a possibly very hard to diagnose runtime exception.

3. The .NET team wanted to deprecate it, CoreFx was a terrific opportunity to cut some dead wood or pursue a new best practice. Lots of examples of this, String.GetEnumerator() is one that usually stumps programmers, justification I heard from a team member that it isn't efficient enough. Obsolete .NET 1.x classes like ArrayList are more obvious.

I can't be sure why Thread.Yield() fell on the floor, but it is used heavily in the CoreCLR implementation (YieldProcessor and __SwitchToThread) so high odds that it fits bullet 3. Microsoft has been pushing hard to make their operating systems and frameworks more friendly to mobile devices, the kind of platform where they have not competed well. Threads are definitely not friendly.

Good odds that they want you to use Task.Yield() instead.

Count