[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: The world needs process-orientation

Hi All,

This was an interesting discussion. Perhaps a bit academic at times, but if
that helps to give students concurrency (and formal approaches) exposure
from the beginning (and not in the last year when the brainwashing has
already happened), the better. Van Roy took this approach, although he is
lonely in the desert, but the result is Oz. A pitty it is rather heavy, but
conceptually a master piece. 

On our side, we have been working on something along the lines of what
Andrew describes below. You can see it as successor to the Virtuso RTOS, but
it takes the same pragmatic approach to CSP. In the real world, and this is
mostly embedded, code size and real-time still matters. And whether we like
it or not, C is the only language really used. It is almost a must, even if
for the wrong reasons. In the automotive sector it comes with the MISRA
rules. Basically 140 rules telling you what you should not do when
programming in C. Apparently there are another 50 rules that never made it
to the standard. Bottom line is however that it works even if the MISRA
rules are a good argument for dropping C altogether. If there would be an
alternative readily availabe, portable, having good IDE's, code-size, low
level control, etc. ... Airbus is using it for all their safety critcal
software. But I must admit, nobody writes the C code anymore. It is
generated from a higher level modeling environment like SCADE. Also in other
domains code generation is starting to replace code writing (e.g. using
matlab/simulink and other tools). C is becoming the new assembler.

Hence, I decided to give it a try and let this community have a look at
OpenComRTOS. This "RTOS" is actually more designed like a scalable
communication layer (for "Tasks") that becomes an RTOS by adding a
preemptive scheduler. It is all based on Packet Switching. It is also
designed to be distrubuted by design. It is static however. Most (deeply)
embedded devices can't have the overhead of dynamic support. It was also
formally modeled using TLA. We had hoped that the formal model would help us
to proof its correctness, but while the models do not show errors, we
learned that it's main use is to help to define a better (cleaner and
meaner) architecture. It helps you to reason about the architecture because
of the rigor, but also because of the abstraction.

Until today, we have more or less finished the L0 layer. The mapping to
"CSP" is as follows:

Processes -> called Tasks
Channels -> called Ports

In? data -> SendPacket(NW)(W)(T)(Async)

Out! Data -> ReceivePacket(NW)(W)(T)(Async)

PAR -> tasks are statically created at compile time. There are Start, Stop,
Suspend, Resume services.

Essentially, what the RTOS does is shuffeling around packets. The Packet has
a(hidden) header and payload 5size defined at compile time).

The major difference is that the services can be used asynchronously and
that we use fixed size packets in L0. The L0 level services are sufficient
to be used in real applications. Also, everything is priority ordened, also
the communication, to preserve hard real-time behaviour.
Our MLX targets have 32KB program memory and 2K RAM. However we spend a lot
of time trying to get the smallest set of services (like primitives).
It was a bit amazing to find a lot of similarities with the internals of the
Transputer (where a lot of the HW support is achieved by manipulating linked
lists in the hardware).

We are currently defining a first L1 layer, build on L0 services. We look
first at Virtuoso (counting semaphors, FIFOs, mailboxes, resource locks,
memory pools, ...) but the idea is that L1 can also emulate other RTOS. (if
the semantics allow it). L1 can handle any size data communication.
A nice "Object" aspect of the L1 objects is that they are conceptually like
Ports in a lego-like fashion.

E.g. a FIFO can be seen as a Port with 2 waiting lists and 2 counters. A
semaphore has one counter and one waiting list. A L0 Port just 2 waiting
lists, no counters. The sorting of the waiting lists can be different. E.g.
in a FIFO one sorts according to FIFO order, not in order of priority.

The L2 layer is more intended for WAN or LAN type communication and soft
real-time and uses L1 and L0 packets as headers.

Code size: see attached file.

Design: see attached file (L0, not fully complete).

Formal model: see attached file.

Targets: running on the MLX16 internal 16bit micro of Melexis and on top of
Windows using sockets to emulate the parallel processing. (each node is a
Windows process). A system generation utility generates the include files
and datastructures from an xml description.
The Windows version can be ported to Linux and serves simultanously as a
logical simulator (task source code compiles on any target) and a 'host
server'. E.g. a system can be built that has embedded targets and host PCs
as nodes in the network. This is also a way to get access to host services
from an embedded target. 

Our goal is to give OpenComRTOS a widespread distrubution. For the
industrial worls we target OEM type 'Open Licenses'. An Open License
provides not just binary, but also source code, formal models, design docs,
test suites, etc. We envision binary licenses as well, and are willing to
provide it free of charge for academic use.

If anyone is interested, to use it or to engage in further cooperation,
please let me know.

Best regards,

Eric Verhulst

----------------------  FROM : --------------------------
   Skype me at: ericverhulstskype
   Mob. +32 477 608339
   Systematic Systems Development Methodologies
   Trustworthy Embedded Components
" "Concept" is a vague concept", L. Wittgenstein 

-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Koehne Kai
Sent: Tuesday, June 13, 2006 9:42 AM
To: Andrew Delin
Cc: occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx
Subject: Re: The world needs process-orientation

Hi Andrew,
A mature occam compiler for an infrastructure like Java and .NET would
definitely help to "spread the word". In fact I took part in a lecture
series at my university that had exactly the same goals, the grid-occam
). If I will find the time, I will prepare a short paper for the upcoming
WoTUG conference that describes the latest achievement of this project, an
occam2Java compiler that supports a subset of occam 2.1. 
However, there are a few obstacles that you have too keep in mind. First,
the language constructs of occam are difficult to map efficiently to
constructs of the Java or .NET intermediate language. Second the creation of
concurrency (threads) is in both platforms pretty expensive (at least in
comparison to KRoC). Finally, if you really want to use occam as a kind of
coordination language, you have to find a convenient method to deal with
things like object creation within occam.
The bottom line is maybe that an optimal POP language for these platforms
would take the process model from occam, and integrate it somehow with the
world of object orientation ... oh, and to be acceptable for the masses, the
syntax should resemble C ;-) Maybe something like Honeysuckle?
I myself have just finished my master thesis, and will deal with something
completely different in my PhD project. However, I would really love to see
a mature POP language for Java or .NET, and would happily volunteer to spend
some spare time for this :-)
Kai Koehne

PS: I currently plan to publish the sources of my Occam2Java compiler at
sourceforge, and would be very pleased to see if anybody would take
advantage of it ;-) Have to ask the university first, though.

Von: owner-occam-com@xxxxxxxxxx im Auftrag von Andrew Delin
Gesendet: Di 13.06.2006 04:01
An: Allan McInnes; tjoccam@xxxxxxxxxxx
Cc: occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx
Betreff: RE: The world needs process-orientation

This has been a fantastic discussion - I'm very glad there's such interest
and belief in POP.

I agree with the view that we need more languages that express
process-oriented ideas naturally; I've found libraries that extend C++ and
Java to be rather clumsy.

I would be interested to collaborate in creating a small, experimental,
Occam for .Net -- if anyone would like to collaborate, please get in touch.

This would be a small subset of Occam/KROC constructs, for demonstration
purposes of the power of POP. If we could compile Occam DLLs to include in
mixed language .Net projects, this could be a powerful demonstration.
The idea is that we can achieve a separation of concerns and Occam-style
code can deal with the parallel aspects. We might achieve some mindshare if
the language interoperates with convention blobs of code.

Any takers?


-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Allan McInnes
Sent: Tuesday, 13 June 2006 2:20 AM
To: tjoccam@xxxxxxxxxxx
Cc: occam-com@xxxxxxxxxx; java-threads@xxxxxxxxxx
Subject: RE: The world needs process-orientation

Quoting tjoccam@xxxxxxxxxxx:
> > So apart from making good business using COP
> Is there a good reason for using this acronym? Everyone else seems to 
> have settled on "process-oriented programming". Unanimity, if 
> possible, helps in being heard.

The term "concurrency-oriented programming" (or COP) has been widely used in
the Erlang community for a number of years. The term has since gained
currency outside of the Erlang community, and I have seen it used in several
different forums to refer to lightweight process-based approaches in

Allan McInnes <amcinnes@xxxxxxxxxx>
PhD Candidate
Dept. of Electrical and Computer Engineering Utah State University

Attachment: OpenComRTOS_CodeMeasurements_27012006.pdf
Description: Adobe PDF document

Attachment: OpenComRTOS_AR_v1.0.14.pdf
Description: Adobe PDF document

Attachment: Formal Model OpenComRTOS.pdf
Description: Adobe PDF document