Well, if you're using actual .NET, you'll be running on Windows, which
isn't a real-time operating system to start with - you just don't get
the guarantees you need for proper real time systems.

Hello, obiwanjacobi!

Here is an article that can help you get additional info on doing real time
managed sofrware
http://blogs.msdn.com/ricom/archive/2006/08/22/713396.aspx

--
With best regards, Vadym Stetsiak.
Blog: http://vadmyst.blogspot.com

You wrote  on Thu, 17 Jan 2008 23:17:17 -0800 (PST):

o> Is it possible? What would be the biggest problem to solve?
o> My guess is the Garabage Collector. You'd kind of want to be able to
o> tell it to stop collecting while you're in a piece of critical code.
o> Are there techniques to manage you're own object instances in such a
o> way the the GC 'never' runs. Or can you run the GC manually and will
o> it 'never' run automatically?

o> I'm investigating if it is possible to write real-time synth software
o> (VST) in .NET....

o> Thanx, --Marc

Hi Marc,

I can tell you about my experience writing real-time (near real-time)
applications in C#.
We had to solve several garbage collection related problems.

The main problem is propagation of objects to the second generation.
Collecting objects in generations 0 and 1 (short living objects) is
very fast. It is performed all the time in background and has almost
no impact on performance. However collection of objects in second
generation took about 10 seconds and was performed very often (once
per several minutes), during which all other processing froze, which
was unacceptable.
Objects in second generation were primarily cached objects and objects
in queues. They lived in cache(queue) for certain time and were
deleted later.
So the shorter object lives the better it is. We had to implement
approach when an object either existed forever, or lived for a very
short time.
This can be done in many ways, like precreating objects in queues and
later assigning data to them instead of putting new objects in; or
implementing object pools.
And I think you would do the same in an environment without GC
(however there you'd like to avoid allocations, here you want to avoid
collections:) )
We didn't remove propagation into the second generation completely,
but the collection occured so rarely that we could afford it to
happen.

If you have this kind of small propagation into 2nd generation you can
run GC when it's not critical for your application to hang for some
time. Full collection shall not run by itself again until memory
finishes.

Also we got rid of short-living Large Objects (object whitch are more
that 85kb. They go into Large Object Heap and are processed
differently by garbage collector).

We had to struggle with memory consumption, because of the nature of
our application. I'm not saying that .NET uses more memory than
something else. But there are some things to keep in mind. Like that
actual memory limit for .NET application on win32 is about 1.5GB, an
object takes at least 12 bytes etc...

From the performance perspective I think purely computational programs
in C# can be written to run not slower than similar in C++. However I
don't know what you might expect from interactions of programs in C#
with other systems, like sound system.

Thanks,
Sergey Zyuzin