Expressing inter thread dependencies

Hello everybody,

I'm developing a source code transformation system for real-time
systems currently, i.e. I want to map the application (a set of event
handlers) to a run-time or operating system semi-automatically (if
anybody is interested in the background - see below, of course,
comments are welcome there, too ;-)). Therefore, I have to be able to
express dependencies between different event handlers (some
predecessors provide data for a common successor and things like
that). I thought about adding some intrinsic functions for this
purpose. Is this the right way or is there a better solution?

Any comments are welcome!

Ciao, Fabian

Background:

One problem when building real-time systems is the mapping of the
software components making up the application to an underlying
run-time or operating system or even bare metal. In other words: the
application has to be mapped to event handlers that are implemented
with the measures stated before (eg. threads, semaphore, schedule
table scheduler ...). In many cases the properties run-time or
operating systems used imply restrictions on the application or even
modeling level (event handlers never block, are always preemptive
...), a quite famous example for such implications is the discrepancy
between time-triggered (TT) and event-triggered (ET) real-time
systems. Applications developed for TT/ET systems can hardly be
transformed into applications for ET/TT systems or vice versa, because
the control flow abstractions employed in these approaches are very
different.

My idea is to strip as much run-time or operating system dependent
information as possible, and thus, get an almost independent
representation. Well such an independent representation is a global
control-/data-flow graph and some additional information (mutual
exclusion of certain parts of the cfg, and, of course, dependencies
between different event handlers). This representation can then be
mapped to operating systems exposing different properties (eg. tt or
et).

How I came across LLVM? Well, I do not want to target bare metal with
the tool, but some kind of operating system, as the LLVM
infrastructure offers a C-backend I am able to target any operating
system providing a C-API. First I had hacking in GCC in mind, but
after having a more thorough look into the GCC documentation convinced
me not to do this. On the GCC mailing list I got a hint to LLVM when I
asked for a C-backend for GCC. After playing around a bit with LLVM, I
decided to use LLVM, because of its great documentation, its clean and
straight-forward design and it because it seems to be easily
applicable also for beginners.

A gratuitous plug for a recent research project: If you use LLVM, you can also get a compiler called SAFECode that (a) enforces memory safety with very low overhead, and (b) defines a subset of C for which you get memory safety with *no* run-time checks. The latter work was specifically aimed at embedded systems. In fact, we called the language subset "Control C" :^).

If you're interested, here are a couple of papers on these issues:

(1) "Memory Safety Without Garbage Collection for Embedded Applications"
Dinakar Dhurjati, Sumant Kowshik, Vikram Adve and Chris Lattner
ACM Transactions in Embedded Computing Systems (TECS), February 2005.
http://llvm.org/pubs/2005-02-TECS-SAFECode.html

(2) "Enforcing Alias Analysis for Weakly Typed Languages"
Dinakar Dhurjati, Sumant Kowshik, and Vikram Adve
Technical Report #UIUCDCS-R-2005-2657, Computer Science Dept., Univ. of Illinois, Nov. 2005.
http://llvm.org/pubs/2005-11-SAFECodeTR.html

SAFECode is a research prototype and so not yet robust, but we aim to make it robust and distribute it publicly. You can get the current version with that caveat.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

If you're interested, here are a couple of papers on these issues:

(1) "Memory Safety Without Garbage Collection for Embedded Applications"
Dinakar Dhurjati, Sumant Kowshik, Vikram Adve and Chris Lattner
ACM Transactions in Embedded Computing Systems (TECS), February 2005.
http://llvm.org/pubs/2005-02-TECS-SAFECode.html

(2) "Enforcing Alias Analysis for Weakly Typed Languages"
Dinakar Dhurjati, Sumant Kowshik, and Vikram Adve
Technical Report #UIUCDCS-R-2005-2657, Computer Science Dept., Univ.
of Illinois, Nov. 2005.
http://llvm.org/pubs/2005-11-SAFECodeTR.html

SAFECode is a research prototype and so not yet robust, but we aim to
make it robust and distribute it publicly. You can get the current
version with that caveat.

that really looks interesting at first glance, I will definitely have
a closer look at it. Thank you :slight_smile:

Ciao, Fabian

SAFECode sounds very interesting. How can we get our hands on it?