[Proposal] Real-Time specification for C#

[4creators]

Real-Time specification for C#

• Proposed
• Prototype
• Implementation
• Specification

Rationale

Real-Time specification for C# idea is based on similar solution available for many years in Java - Real-Time specification for Java.

Main reason behind proposal is a dramatic change in embedded applications market where advancements in IoT, automotive, edge AI, robotics, and mobile applications together with democratization of market by continously decreasing barriers to entry allow for the whole new class of revolutionary embedded solutions - see Meet the AI Tennis Ref That Can Be Bought for $200 by Bloomberg. Many of this applications require predictability of execution as an additional correctness condition besides giving correct results. Examples include software for drones, robots, computer vision, medical devices and applications but even current non real- time software may benefit from specification i.e. media, games or other time dependent applications.

Availability of .NET Core Real-Time C# would allow for large expansion of framework usage in particular due to fact that it can run even today on soft real-time systems i.e. realt-time linux. Fact that Windows currently does not have real-time profile should not prevent realizing this proposal.

Specification scope

Support for Hard Real-Time and Soft Real-Time Systems

Support for all current software - should run on RT C# without modifications

Thread Scheduling and Dispatching, Thread Synchronization, Priority Inversion Algorithm(s)

Memory Management and Access including Physical Memory Access

GC Algorithms and GC Time Constraints

Resurce Sharing, Access Synchronization

Asynchronous Events, Threads and Transfer of Control.

Alternatives

None

[Joe4evr]

I don't know, but it sounds like some of the items on your list can be solved by a good NuGet package. And the rest sound like they should be filed over at CoreCLR because those are the runtime's business, not the language.

[4creators]

I don't know either - based on Java approach it was part of language specification which perhaps should be understood as whole package comprising runtime, jit, gc, library and language specification. Unfortunately it seems that there is no good place to file general architecture proposals spanning whole framework.

[svick]

From the linked Real-Time specification for Java:

The Real-Time for Java Expert Group […] was given the responsibility of producing a specification for extending The Java Language Specification and The Java Virtual Machine Specification and of providing an Application Programming Interface that will enable […]

Do you know which parts of the The Java Language Specification did they extend?

[tannergooding]

I agree that most of these items are runtime items and are not actionable items from the language perspective.

What I would do, if I were filing these, would be to log issues on CoreCLR requesting that a certain missing feature be added. Give concrete examples of the problem that exists and how this is fixing it. Give examples (like JVM) of other real-world code that provides the functionality.

Then create a language request in C# on how the language should expose the CLR functionality (were it to be implemented). Again, provide concrete examples, etc. Additionally cover why it is worthwhile for the language to expose it, rather than CoreFX exposing APIs, etc. A lot of the C# language keywords are just syntax sugar on-top-of existing CoreFX APIs. So, often times, you may get told: "Let CoreCLR implement it, let CoreFX expose it, let us see adoption, and then we will consider implementing it".

Finally, link the two issues together.

[4creators]

OK I will split issue into parts relating to C# Language Specification, coreclr required changes for RT support and user exposed APIs which should go to corefx for API Review process and later close this issue.

[sharwell]

One more thing to keep in mind: there are places in the C# language where some flexibility is afforded to the compiler to do things in different ways. In cases where real time support only places constraints on the compilation output, but the language semantics are otherwise the same, it may be candidates for issues in dotnet/roslyn. These would primarily target cases where the current compiler output can't be handled by the AOT/JIT that ends up supporting the real time system.