[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: occam REPL
Larry,
I took another look at your paper and what you call resources is not the
same as the standard concept in embedded software. A variable, used by a
process, is not a resource in this context. Of course, it is a resource in
your meaning because it is a resource that is always owned by a specific
process and never used/shared by any other process. The resource is internal
to the process and actually, it doesn't even matter it is there for any
other process because it is outside its scope.
The issue in when the resource is to be shared by several processes. Such a
resource is a 'logical' resource, in practice a nameholder for a physical
resource that needs to be shared. Can be a piece of memory, a hardware unit,
a communication line, etc. The issue is that when a given proces got hold
of a resource, it creates a critical section. Actually, it is often the
opposite. Because access to the resource must be atomic, one needs a
resource to protect that. Typical example: a communication protocol on a
single communication line. If several process start putting at random there
packets on the line, the receiver will see incoherent packages and will not
be able to reconstruct the communication packets. Or will not be able to
figure out what the packet means. So in CSP style, you would add a specific
process just before the communication line, sequentialising the packets to
keep the coherence.
That's the first and simple explanation. Next comes the issue of real-time.
When a process ownes a resource, it can bock other processes from further
progess, including processes that have a higher priority. The issue here is
the problem of priority inversion. Bottomline: the kernel needs to boost
prorities to reduce the blocking time. Remember that the CPU is also a
resource and will only execute the processes in a given scheduled sequence
(preemtable). In your paper you say 'simultanously' but that is just a
metaphore is presume?
As said in the previous mail, you can handle this in a resource managing
process but than you have for every resource a specific handler. And how do
you handle that processes can have dynalically changing priorities? How can
such a handling process know about it ? That's what the kernel task does in
a RTOS. It has abstracted away all application specific resource access
scenarios into a single one and as it is the RTOS kernel, it knows the
priority at all times of all processes as it is also the task to schedule
the processes (note: in OpenComRTOS, we only use the term Task,; but you can
equate that to process).
Hopefully, this explains it a bit more.
Best regards,
Eric
PS.
A well documented case was the Marsrover "bug". It was case where VXWorks
was used and the default option was to have priority inheritance support
disabled. Amazing how the marketing guys turned this disaster into a success
story, because they could reset the bit from earth! For real-time experts,
this was simple a case of erronuous software engineering. Of course, in the
lab the problem did not occur because the operating environment was
different. No testing on earth would likely have found the issue.
---------------------- FROM : --------------------------
Eric.Verhulst@xxxxxxxxxxxxxxxxxxxxxx
Skype me at: ericverhulstskype
Mob. +32 477 608339
Systematic Systems Development Methodologies
Trustworthy Embedded Components
http://www.OpenLicenseSociety.org
-----------------------------------------------------------
" "Concept" is a vague concept", L. Wittgenstein
-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of tjoccam@xxxxxxxxxxx
Sent: Monday, August 21, 2006 7:12 PM
To: erv@xxxxxxxxxxx
Cc: tjoccam@xxxxxxxxxxx; 'Andrew Delin'; 'Damian Dimmich';
occam-com@xxxxxxxxxx
Subject: RE: occam REPL
> In CSP/occam
> you can develop an application specific process that interfaces
> between the resource requesters and the resource handling process, but
> that is still application specific (you sequenctialise the access to
> the resource) and is not a solution for the problem of priority
> inheritance. It would be nice if someone would find a solution to do
> away with resources as they are the crucial issue in real-time
> systems, but as long as embedded systems will have physical resources
> to protect, you will need resource management.
> It remains good design practice to solve the application issues with
> resources as much a possible at design time, but alas, there's always
> a minimum critical section.
If I follow you, you seem to be implying a conflict between occam-like
process design and resource management. I see the opposite - a conflict
between resource management and anything other than POP. The slight
extension of occam in my white paper is called "resource-oriented
programming". Of course, what you write in a POP language may be a kind of
simulator --- with details finer than the actual 1 KB of hardware will
support --- and what was prototyped as a process may end up a couple lines
of interrupt code, but that does not change any of the design principles.
Just make sure the final product exactly follows the design. The current
approach dispenses with the design. That is not better than a simulator.
Larry Dickson