Debugging RTOS problems in embedded systems

On Jul 10, 3:59 pm, speedplane <michael.san...@gmail.com> wrote:
[]
>
> Jeez... I hate these newsgroups. Not only is everyone condescending,

sometimes.

> they're also wrong.

I've always been willing to be shown how I am wrong but in this case,
you comments later lead me to see we are talking different
environments - me: embedded and similar applications, you: massively
parallel applications. Different situations, different solutions
needed.

>   ...  I'm not going to explain this any further.

Sorry you want to walk away mad. All I can say is I think your
original explanation left too many hidden assumptions, so I thought
your were not as knowledgable as you might be. There can be a lot of
context left out in these discussions. I do appreciate the links, and
I'll review them.

>  ...  If you
> are interested in transactional programming please read the
> literature:
>
> Here's some info on a possible hardware implementation. It goes into
> detail about the copy stage (part 2) and the checking stage (part 3).
> A quick answer to part 3 is that they use a broadcasting system.
> L. Hammond, V. Wong, M. Chen, B. Carlstrom, J. Davis, B. Hertzberg, M.
> Prabhu, H. Wijaya, C. Kozyrakis, and K. Olukotun  Transactional Memory
> Coherence and Consistency  International Symposium on Computer
> Architecture(ISCA), 2004http://www.cs.ucsb.edu/~arch/cs254/papers/tcc.pdf
>
> If you're more interested in how this effects performance /
> programmability read about the ATOMOS transactional programming
> language.
> B. Carlstrom, A. McDonald, H. Chafi, J. Chung, C. Minh, C. Kozyrakis,
> K. Olukotun The ATOMOS Transactional Programming Language  Proceedings
> of the Conference on Programming Language Design and Implementation
> (PLDI), June 2006http://www.cs.ucsb.edu/~arch/cs254/papers/atomos.pdf
>
> Those two papers will explain the basic concepts of transactional
> programming and you'll soon realize that it is different from ORACLE
> database transactions. Indeed special hardware is indeed not needed,
> but transactional programming may make designing massively parallel
> processors more feasible.

Different contexts, different solutions needed. Since this group is
comp.realtime, you can forgive me not thinking about massively
parallel applications during discussions, can't you? (90% of my
efforts nowadays are DB related, so that comes to mind easily.)

Oh well, have a nice day.
   Ed