Re: embedded or real-time project using Eiffel

On 27 Feb., 01:03, "Emmanuel Stapf [ES]"
<manus_no_s...@[EMAIL PROTECTED]
> wrote:
> I'm not sure what is expensive.

The semantics of memory barriers are difficult and unfortunately not
wide understood.
I also don't understand too much about it. But if read here.

http://msdn2.microsoft.com/en-us/library/ms686355(VS.85).aspx

The cost of a memory barrier depends on the CPU architecture. It is
almost cost free on
current Intel i386 CPU's. It just disables the out of order execution
of the CPU.
But on PPC and SPARC there is a cost. NUMA has a high penality for
this. And the Core3
will have a NUMA Bus instead the current frontside bus.

So your solution might work now for most customers but it is not a
good decision for the
future. I see a very hard future for Eiffel if it can not come up in
the next 10
years with  all the fancy multithreading features that will now come
soon. SUN's
implementation of Rock with transactional memory and lock free
algorithms is the
start of the new area. You should read "comp.programmer.threads" and
you see how
difficult low level thread programming can be.

I just feel that you want to break Einsteins Law:
"Make it as simple as possible but not simpler."
But Multithreading/Multiprocessing is not simple. Looks like you try
to explain
quantum mechanics without tensors.

Eiffel needs more here. I looked into adding OpenMP stuff into my
eiffel compiler, it's
not that difficult but if you act as language lawyer it is very
difficult to specify
the exact effect of the multithreading. Something that people are
still discussing after
ten years of SCOOP. And if you can't came up with this after 10 years
it is the best prove
that the whole concept terrible sucks (the famous exception in a
thread question).