The question is easy to answer: Make the Static. This will put them on the
high frequency heap, and they won't ever be collected.
... now, with that said, this is probably pretty silly. What are you
building that you think GC will just wreck?
Given you level of knowledge about .Net, I would guess you haven't tried any
of this yet, and are shooting in the dark. If this is the case, you may want
to step back and take a bigger look at things.
Figure out your performance and latency requirements, and from there
determine if you can use .Net or not.
In the best case, you're guilty of waaaaay premature optimization, and
you're going to make things worse rather than better.
--
Chris Mullins
hello;
thank you for your response.
I am trying to use .met MF to issue motor control commands
commands can't be delayed for GC action.
Since GC is the system in .net MF it is the one who use/steals cycles from
the cpu.
By using static we can help continuous stream of commands without any
un-timed GC latency.
yes; .net MF/XP are not real time system and only windows CE/Linux are real
time OS.,
However, .net MF CLR is the OS to be concern on the system.
my question now would be:
1- is there any specific technique for CLR (known to you as more
knowledgeable) to be used in this manner to help keep the commands flow
without interruption?
2- short of using real time OS, I want to use .net MF; because it is easy to
use and less time consuming and is really a good way to use embedded MCU.
then what is the best ways to do that with the understanding, that we can't
make .net MF a complete zero latency? there is enough RAM to hold a program.
thank you

Signature
elwolv
> The question is easy to answer: Make the Static. This will put them on the
> high frequency heap, and they won't ever be collected.
[quoted text clipped - 68 lines]
> >> >
> >> > thank you
Chris Mullins [MVP - C#] - 04 Dec 2007 17:51 GMT
You're up against a target I don't think you're going to hit based on advice
from a newsgroup.
Go out, write some prototype code, and get it running. When it doesn't work,
keep trying various approaches until you get something you like.
I suspect you're going to get the compact framework, running on a mobile
device, to work as well as you're hoping. I would like to be wrong, but
based on my work with the Compact Framework, you've got an uphill battle on
your hands. I suspect GC will be one of your concerns, but will be far from
the last...
--
Chris Mullins
> hello;
>
[quoted text clipped - 109 lines]
>> >> >
>> >> > thank you
Ben Voigt [C++ MVP] - 04 Dec 2007 18:47 GMT
> hello;
>
[quoted text clipped - 6 lines]
> By using static we can help continuous stream of commands without any
> un-timed GC latency.
By eliminating allocations (after startup) I think you should be able to
prevent the GC from running.
To do that, you'll need to pool your objects. I think you can use
LinkedList<T> for that as long as you save the LinkedListNode<T> and simply
move it between free and busy lists, always use the methods that take a
LinkedListNode because the only will allocate them.
Also, I hope you aren't doing any string manipulation, because strings can't
be pooled (they are immutable, so the only way to get a new value is to
allocate one). Use byte or character arrays instead of strings.
If you weren't on MF (where there is no interop layer) I'd say use C or C++
to create a native thread for the realtime operations, and pass buffers back
and forth to the managed thread, then don't worry about the GC.
> yes; .net MF/XP are not real time system and only windows CE/Linux are
> real
[quoted text clipped - 98 lines]
>> >> >
>> >> > thank you