We Keep Coding

C# Hard Real Time Thread in RT Linux?

My understanding is that in Linux in order to run a truly Hard real-time application it needs to be compiled as a Linux kernel module and called directly by the kernel. Is that correct? If so does any have any good reading material on the subject? (something that is easy for a non C developer to understand) If not how are they interfaced with the OS to provide deterministic timing?
Is it possible to compile a C# program ahead-of-time with say Mono or .Net Native and have a run as a hard real-time application? The Code would, of course, have to be written so that it is fast and completes in the allotted time so that it does not get preempted. (if I understand how RT works). The idea being that there would be a Hard Real-Time main thread (with unsafe memory), that interfaced via shared memory with one or more Managed C# Thread nonrealtime threads.
If running C# code as Hard Real-time is not an option, would running C code as HRT be an option and then sharing memory with a .net Application?
I found this but it is 4 years old and there was only one answer and I wanted to know if anyone had anymore incite, since then
Can C# .NET be used for hard real-time?

"On-the-run" Debugging/Monitoring

Is there a way/system to debug/monitor code without stopping execution?
In industrial automation control programming (PLC/PAC/DCS) it is possible to connect the debugger while the program is running, and see in the code editor the value of variables and expressions, without setting breakpoints or tracepoints.
As an example, let's have a F# multithreaded application, where code is executed in a continuous loop or triggered by timers. Is there a way to attach a debugger like Visual studio Debugger and see the values of variables and expressions (in the code editor or in a watch pane) WITHOUT interrupting the execution?
It doesn't matter if it's not synchronous, it's acceptable if the debugger/monitor does not capture all the code scans.
I am tasked to create an high level controller for a process plant and I would like to use C# or F# or even C++ with a managed or native application, instead of a PAC system. But being forced to interrupt execution to debug is a huge disadvantage in this kind of application.
UPDATE
First of all thanks to all for their answer.
Based on those answers, though, I realized that probably I need to reformulate my question as follows:
Is anyone aware of any library/framework/package/extension that allows to work with a native or managed application in windows or linux (C#, F# or C++) the exact same way as a PAC development platform, specifically:
1) Put the dev platform in "status" mode, where it shows automatically the runtime value for variables and expressions present in the code exceprt currently visible, without interrupting execution?
2) Create watch windows that show the runtime value of variables and expressions, again without interrupting execution?
Also, what I am looking for is something that (like any PAC platform) offers these features OUT OF THE BOX, without requiring any change in the application code (like adding log instructions).
Thank you in advance
UPDATE 2
It looks like there is something (see http://vsdevaids.webs.com/); does anyone know whether they are still available somewhere?
UPDATE 3
For those interested, I managed to download the last available release of VSDEVAIDS. I installed it and looks working, but it's pointless without a licence and couldn't find information on how to reach the author.
http://www.mediafire.com/file/vvdk2e0g6091r4h/VSDevAidsInstaller.msi
If somebody has better luck, please let me know.

this is a normal requirement - needing instrumentation / diagnostic data from a production system. Its not really a debugger. Its usually one of the first things you should establish in your system design.
Not knowing your system at all its hard to say what you need but generally they fall into 2 categories
human readable trace - something like log4net is what I would recommend
machine readable counters etc. Say 'number of widget shaving in last pass',..... This one is harder to generalize, you could layer it onto log4net too. Or invent your own pipe

With regards to your edited question, I can almost guarantee you that what you are looking for does not exist. Consequence-free debugging/monitoring of even moderate usefulness for production code with no prior effort? I'd have heard of it. Consider that both C++ and C# are extremely cross-platform. There are a few caveats:
There are almost certainly C++ compilers built for very specific hardware that do what you require. This hardware is likely to have very limited capabilities, and the compilers are likely to otherwise be inferior to their larger counterparts, such as gcc, clang, MSVC, to name a few.
Compile-time instrumentation can do what you require, although it affects speed and memory usage, and even stability, in my experience.
There ARE also frameworks that do what you require, but not without affecting your code. For example, if you are using WPF as your UI, it's possible to monitor anything directly related to the UI of your application. But...that's hardly a better solution than log4net.
Lastly, there are tools that can monitor EVERY system call your application makes for both Windows (procmon.exe/"Process Monitor" from SysInternals) and Linux (strace). There's very little you can't find out using these. That said, the ease of use is hardly what you're looking for, and strictly internal variables are still not going to be visible. Still might be something to consider if you know you'll be making system calls with the variables you're interested in and can set up adequate filtering.
Also, you should reconsider your "No impact on the code" requirement. There are .NET frameworks that can allow you to monitor an entire class merely by making a single function call during construction, or by deriving from a class in the framework. Many modern UIs are predicated on the UIs being able to be notified of any change to the data they are monitoring. Extensive effort has gone into making this as powerful and easy as possible. But it does require you to at least consider it when writing your code.

Many years ago (think 8 bit 6502/6809 days) you could buy (or usually rent, I seem to remember a figure of £40K to purchase one in the late 80s) a processor simulator, that would allow you replace the processor in your design with a pin compatible device that had a flying lead to the simulator box. this would allow things like capturing instructions/data leading up to a processor interrupt, or some other way of stopping the processor (even a 'push button to stop code' was possible). You could even step-backwards allowing you to see why an instruction or branch happened.
In these days of multi-core, nm-technology, I doubt there is such a thing.

I have been searching for this kind of features since quite a long time with no luck, unfortunately. Submitting the question to the StackOverflow community was sort of a "last resort", so now I'm ready to conclude that it doesn't exist.
VSDevAids (as #zzxyz pointed out) is not a solution, as it requires significant support from the application itself.
Pod cpu emulators (mentioned by #Neil) aka in-circuit emulators (ICE) and their evolutions are designed to thoroughly test the interaction between firmware and hardware, not so useful in high level programming (especially if managed like .NET).
Thanks for all contributions.

accelerate application with a faster clock in c# or c++

I have different applications written in C# and C++ that communicate between each other. I would like to test this environment with some scenarios that I wrote.
Each scenario runs for different hours.
Is there a way to accelerate everything in order to have the scenarios run in minutes.
The applications may contains some Thread.Sleep(...) or equivalent in C++.
My idea is that a Thread.Sleep(2000) would wait for 2 seconds normally but when accelerated it should only wait for 200 ms.
Unfortunately I cannot change or refactor the code of the applications.
A first idea I have is to run the applications in an "accelerated Windows" system. A sort of wrapper of the OS where time run faster. But I have no idea on how to achieve this.
So any new idea or solution would be great.
Thanx

I don't think "making Windows run faster" is practical, but I would consider intercepting the Sleep() method calls and short-circuiting them. I haven't looked, but Thread.Sleep() will probably thunk down somewhere to a Win32 API or an NT API (http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspx).
You can use depends.exe from the Windows SDK and a debugger to see what your code uses, but I suspect (unless you know otherwise) that it won't simply be a Sleep() call, it'll more likely be a call waiting on some system object, I/O or a trigger, using WaitForMultipleObjectsEx() and friends.
Have a look at Detours from Microsoft Research for API interception http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspx
There are are also various writings by Jeffry Richter and Matt Pietrek on the subject. In fact here's a codeproject article inspired by one of those;
http://www.codeproject.com/Articles/5178/DLL-Injection-and-function-interception-tutorial

Embedding LuaInterface in a C# application has slow performance?

I've embedded the LuaInterface project into an application written in C# using .NET Framework 4.0. After compiling LuaInterface and Lua 5.1 I've referenced them in my application and created a Lua VM and exposed a few .NET classes. When the Lua VM doesn't make many calls, performance is not affected at all; but when it starts to call a larger number of .NET functions the entire application becomes slow and unresponsive.
In response to this, I've made an additional thread to run the Lua VM on. For some reason though, the thread on which the GUI is updated will not update while Lua is doing a function call, resulting in stuttering in the GUI. When moving a window around, you can clearly see that it doesn't respond for a little while, then moves, doesn't respond, etc.
How can I solve this issue? I was under the impression that giving Lua its own thread, a different thread shouldn't be affected! Is this purely related to my own code in some way? Does LuaInterface have a some serious issues calling .NET functions (performance-wise)? What else could I use?

I didn’t try to compile LuaInterface against .NET 4. So far I used only the precompiled dlls. I know that you can speed up mixed image assemblies in .NET 4 by setting the to zero. According to MS: .NET Framework 4, a streamlined interop marshalling architecture provides a significant performance improvement for transitions from managed code to unmanaged code.
http://msdn.microsoft.com/en-us/library/ff361650.aspx
Keep us updated in case you find a trick which works for you. In Visual Studio 2010 you can actually build against .NET 2 so if I were you I would try to create a dummy app and compile it against multiple targets. It might help you to quantify the speed degradation when you are using .NET 4.
If you give us some code maybe I could play with it a bit and figure out what is wrong. I am really interested in LuaInterface and keen to figure out what is wrong.
Since I don't have a code sample I am just speculating on this; but it is possible that the issue is related to your UI not being thread safe. It is pretty common to have locking issues for example with Windows Forms Controls.
How to: Make Thread-Safe Calls to Windows Forms Controls
http://msdn.microsoft.com/en-us/library/ms171728(v=vs.80).aspx

Long time running applications

I'm going to design an Application (C# or VB.NET) which use .NET Framework to run for very long time. It may be restarted every year or even more...
Is there anything (using special design patterns or so) which I must care about in designing "Long time running applications in .NET"?
Is .NET ever a good platform for these kind of applications or I should use other platforms such as J2SE?
(It's not a web application.)

I actually would say that using .NET is well-suited to long running applications. Managed code, in general, tends to do fairly well in this type of scenario, as a compacting GC helps prevent issues that can arise due to memory fragmentation over time.
That being said, it's difficult to give much guidance, as there's very little information in the question itself. The "every year or more" run times is not enough information to say that a particular framework or language choice would benefit - any language can work, as the issues that arise from long running applications tend to be more design issues, and less framework/language/toolset/etc.
I've written some .NET-based applications which run as services and stay continually running for very long times, and never had any issues with the application (at least none related to the technology itself).

I'd worry less about keeping an app running and more about what happens when it inevitably stops - and make no mistake, it WILL stop.
There are many factors that can go wrong; a crash, server fault, network failure or someone simply stopping the app. The true work will be resuming the application's tasks after it restarts.

.NET's garbage collector is very good, so as long as you don't have any non-obvious memory leaks, that should be OK. "Non-obvious" includes not releasing event-handlers when you're truly done with them., using lambda expressions for event handlers in other classes, and that sort of thing.
Be sure that you're catching and logging all unhandled exceptions. If it does die, you'll want to know why.
Also, take a look at the application restart support in Windows 7. This can restart your app in case it does fail. Although it's written for unmanaged code, it's accessible for .net in the Windows 7 API code pack.