Ravenscar

Ravenscar

[Stephan Heinemann]

Is there a designated newsgroup regarding questions about
the Ravenscar Profile, e.g., about motivations that led
to the made restrictions, or would this be the place to
post such questions?

PS:
I already read the new 2003 guide providing a rationale,
but some questions remained...

Re: Ravenscar

[Lutz Donnerhacke]

* Stephan Heinemann wrote:
> Is there a designated newsgroup regarding questions about the Ravenscar
> Profile, e.g., about motivations that led to the made restrictions, or
> would this be the place to post such questions?

Yes: Use this group, please.

Re: Ravenscar

[Matthew Heaney]

"Stephan Heinemann" <zombie@cs.tu-berlin.de> wrote in message
news:bgjdb3$6f0$1@news.cs.tu-berlin.de...
>
> I already read the new 2003 guide providing a rationale,
> but some questions remained...

To which guide/rationale are you referring? Do you have a URL, etc?

Re: Ravenscar

[Phil Thornley]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:BGsXa.2641$jp.1539@newsread4.news.pas.earthlink.net...
>
> "Stephan Heinemann" <zombie@cs.tu-berlin.de> wrote in message
> news:bgjdb3$6f0$1@news.cs.tu-berlin.de...
> >
> > I already read the new 2003 guide providing a rationale,
> > but some questions remained...
>
> To which guide/rationale are you referring? Do you have a URL, etc?
>
>
>

The following message from Alan Burns (Chairman of the HRG) went out on
the HRG mailing list in January:

------------------------------------
I'm pleased to inform everyone that the Guidelines
report that the HRG has been working on over the
last couple of years has now been published as a
University of York Technical (Yellow) report. In
runs to some 74 pages and can be downloaded via
our ftp site:

ftp://ftp.cs.york.ac.uk/reports

and click on YCS-2003-348.pdf

or get at it from my home page.

The HRG will offer this report to WG9 as a
potential ISO technical report.
------------------------------------

HTH

Phil


--
Phil Thornley
Programmes, Engineering
Warton

Re: Ravenscar

[Stephan Heinemann]

> To which guide/rationale are you referring? Do you have a URL, etc?

The guide to which I was referring can be downloaded at
"ftp://ftp.cs.york.ac.uk/papers/rtspapers/R:Burns:2003.pdf".

Shortly I will post some questions. I need to order my stuff first...

Stephan

Re: Ravenscar - Scheduling

[Stephan Heinemann]

Ravenscar was definied with pre-emptive fixed priority scheduling in mind.
I also read that non pre-emptive scheduling could be applied. I am working
with Petri Nets and need do control the preemption points of the scheduler
in order to model the whole system (I am working on a code-generator).
Co-operative scheduling would be ideal for this purpose. I need somehow
prevent the scheduler from preempting actions (Ada code snippets) which
are associated with transitions. Any ideas?

Thanks in advance,
Stephan

Re: Ravenscar - Scheduling

[Stephan Heinemann]

> Ravenscar was definied with pre-emptive fixed priority scheduling in mind.
> I also read that non pre-emptive scheduling could be applied. I am working
> with Petri Nets and need do control the preemption points of the scheduler
> in order to model the whole system (I am working on a code-generator).
> Co-operative scheduling would be ideal for this purpose. I need somehow
> prevent the scheduler from preempting actions (Ada code snippets) which
> are associated with transitions. Any ideas?

I guess I found what I was looking for in Alan Burns
"Non-Preemptive Dispatching and Locking Policies"... The "execution token"
seems to be exactly what I need. Anyway, further ideas are still welcome.

Stephan

Re: Ravenscar

[Stephan Heinemann]

The rational given for simple barriers is to guarantee a temporally
deterministic bounded epilogue. I do not see the non-determinism. If
a complex function call were made, this function could, of course, call
other subprograms or even other protected entries (with the same complex
epilogue). But the WCET of subprograms or the WCBT of protected entries
can (?) be determined. So, I do not really understand the given reasoning. 
Of course, the RTSS can be more efficient without the need to
reevaluate barriers.

Stephan

Re: Ravenscar

[Rodrigo Garcia]

"Stephan Heinemann" <zombie@cs.tu-berlin.de> wrote in message
news:bgjdb3$6f0$1@news.cs.tu-berlin.de...
> Is there a designated newsgroup regarding questions about
> the Ravenscar Profile, e.g., about motivations that led
> to the made restrictions, or would this be the place to
> post such questions?
>
> PS:
> I already read the new 2003 guide providing a rationale,
> but some questions remained...

You can also refer to / participate in the IRTAW, the workshop that
originated the Ravenscar Profile.
http://www.hurray.isep.ipp.pt/irtaw2003/

Rodrigo

Re: Ravenscar - timouts

[Stephan Heinemann]

In YCS-2003-348 on pages 33/34 is expained how timeouts can be programmed
with Ravenscar. The last three lines show how a client must invoke the
timed call.

Timer_Control.Set_Time(Some_Time);
PO.Call(Timeout);

Between these two calls the client may be preempted. The task Timer could
therefore have no effect on PO, since Call'Count = 0. Then the client is
released again and blocked on Call...
Until now I have not found another solution...

Stephan

Re: Ravenscar - Multiple Protected Entries

[Stephan Heinemann]

Multiple protected entries are prohibited, saying that more than exactly
one barrier could be opened at the same time and therefore introducing
non-determinism as more than one task were able to enter the resource
(YCS-2003-348 4.1.4). I cannot follow this reasoning as 
FIFO_Within_Priorities is used. Can anybody help me with this?

Thanks in advance,
Stephan

Re: Ravenscar - Multiple Protected Entries

[Jeffrey Carter]

Stephan Heinemann wrote:
> Multiple protected entries are prohibited, saying that more than exactly
> one barrier could be opened at the same time and therefore introducing
> non-determinism as more than one task were able to enter the resource
> (YCS-2003-348 4.1.4). I cannot follow this reasoning as 
> FIFO_Within_Priorities is used. Can anybody help me with this?

Suppose 2 tasks have the same priority, are blocked on 2 entries of a 
protected object, and both barriers become True at the same time. How do 
you determine which of the 2 tasks executes next?

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles

Re: Ravenscar - Multiple Protected Entries

[Stephan Heinemann]

> Suppose 2 tasks have the same priority, are blocked on 2 entries of a 
> protected object, and both barriers become True at the same time. How do 
> you determine which of the 2 tasks executes next?

The one which suspended first - FIFO_Within_Priorities. But which one
suspended first? ...

Stephan

Re: Ravenscar - Multiple Protected Entries

[Jeffrey Carter]

Stephan Heinemann wrote:
>>Suppose 2 tasks have the same priority, are blocked on 2 entries of a 
>>protected object, and both barriers become True at the same time. How do 
>>you determine which of the 2 tasks executes next?
> 
> 
> The one which suspended first - FIFO_Within_Priorities. But which one
> suspended first? ...

FIFO_Within_Priorities has nothing to do with it. There are 2 queues, 
and each has only 1 task in it, so each task is at the head of its 
queue. Each task is next to execute when its respective barrier becomes 
True. And the language rules do not specify which task executes first. 
So it is non-deterministic which task will execute next.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas

Re: Ravenscar - Multiple Protected Entries

[Stephan Heinemann]

> FIFO_Within_Priorities has nothing to do with it. There are 2 queues, 
> and each has only 1 task in it, so each task is at the head of its 
> queue. Each task is next to execute when its respective barrier becomes 
> True. And the language rules do not specify which task executes first. 
> So it is non-deterministic which task will execute next.

Thank you, Jeff. Is there a section in the ARM which mentions this issue
explicitly or not?

Stephan

Re: Ravenscar - Multiple Protected Entries

[Stephan Heinemann]

> FIFO_Within_Priorities has nothing to do with it. There are 2 queues, 
> and each has only 1 task in it, so each task is at the head of its 
> queue. Each task is next to execute when its respective barrier becomes 
> True. And the language rules do not specify which task executes first. 
> So it is non-deterministic which task will execute next.

I am a littlebit confused... In 9.5.3 you can find the following
statement: "If calls from two or more queues are simultaneously
eligible for selection, the default entry queuing policy does not
specify which queue is serviced first.". The default queuing policy is
FIFO_Queuing. In section D.4 you can find the following: "When more
than one condition of an entry_barrier of a protected object becomes
True, and more than one of the respective queues is nonempty, the call
with the highest priority is selected. If more than one such call has
the same priority, the call that is queued on the entry whose
declaration is first in textual order in the protected_definition is
selected. For members of the same entry family, the one with the lower
family index is selected." Well, what shall I believe now?

Stephan

Re: Ravenscar - Multiple Protected Entries

[Jeffrey Carter]

Stephan Heinemann wrote:
> 
> I am a littlebit confused... In 9.5.3 you can find the following
> statement: "If calls from two or more queues are simultaneously
> eligible for selection, the default entry queuing policy does not
> specify which queue is serviced first.". The default queuing policy is
> FIFO_Queuing. In section D.4 you can find the following: "When more
> than one condition of an entry_barrier of a protected object becomes
> True, and more than one of the respective queues is nonempty, the call
> with the highest priority is selected. If more than one such call has
> the same priority, the call that is queued on the entry whose
> declaration is first in textual order in the protected_definition is
> selected. For members of the same entry family, the one with the lower
> family index is selected." Well, what shall I believe now?

All compilers have to implement the core language, and section 9 is part 
of the core language. Annex D (Real-Time Systems) is an optional annex 
that a compiler vendor can choose not to implement, to implement 
partially, or to implement completely. If your compiler implements Annex 
D and you don't mind being limited to compilers that implement Annex D, 
then you can rely on the entry that appears first in the protected 
unit's specification. If you want to be portable to all compilers, you 
can only count on the things in the core language. This appears to be 
the intention of Ravenscar, since it limits protected objects to a 
single entry to avoid non-determinism.

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall

Re: Ravenscar - Multiple Protected Entries

[Stephan Heinemann]

> All compilers have to implement the core language, and section 9 is part 
> of the core language. Annex D (Real-Time Systems) is an optional annex 
> that a compiler vendor can choose not to implement, to implement 
> partially, or to implement completely. If your compiler implements Annex 
> D and you don't mind being limited to compilers that implement Annex D, 
> then you can rely on the entry that appears first in the protected 
> unit's specification. If you want to be portable to all compilers, you 
> can only count on the things in the core language. This appears to be 
> the intention of Ravenscar, since it limits protected objects to a 
> single entry to avoid non-determinism.

But without Annex D, there would be no monotonic time which is an integral
part of Ravenscar...

Totally confused,
Stephan

Re: Ravenscar - Multiple Protected Entries

[Colin Paul Gloster]

Stephan Heinemann wrote:
"Multiple protected entries are prohibited, saying that more than exactly
one barrier could be opened at the same time and therefore introducing
non-determinism as more than one task were able to enter the resource
(YCS-2003-348 4.1.4). I cannot follow this reasoning as 
FIFO_Within_Priorities is used. Can anybody help me with this?"

In article news:3F35AFA7.1030905@spam.com , Jeffrey Carter wrote:

"Suppose 2 tasks have the same priority, [..]"

The subject is "Re: Ravenscar - Multiple Protected Entries", not Ada
95. Ravenscar requires unique priorities.

Cheerio,
Colin Paul Gloster

Re: Ravenscar - Multiple Protected Entries

[Stephan Heinemann]

Colin Paul Gloster <Colin_Paul_Gloster@acm.org> wrote:
> The subject is "Re: Ravenscar - Multiple Protected Entries", not Ada
> 95. Ravenscar requires unique priorities.

Are you sure? Could you provide a reference for this, please?

Thanks,
Stephan

Re: Ravenscar - Multiple Protected Entries

[Colin Paul Gloster]

Colin Paul Gloster alleged:
"The subject is "Re: Ravenscar - Multiple Protected Entries", not Ada
95. Ravenscar requires unique priorities."

In article news:bhb72d$qv$2@news.cs.tu-berlin.de Stephan Heinemann asked:

"Are you sure? Could you provide a reference for this, please?"

I could look a bit more, but I have not found support for my claim.
However in my search I rediscovered something which shows that Jeff
Carter's post which I was following up to should not be ignored
because a Ravenscar task's priority can temporarily change: slide 20,
page 16 of YCS-2003-348.pdf.

Re: Ravenscar - Multiple Protected Entries

[Colin Paul Gloster]

My claim yesterday of unique priorities
is also refuted by
"[..] you can even have a case on which
two tasks have the same priority" from page
27, slide 31 of Version 1.1 . 30 November, 2000
of "Final Report . Phase 1" of Experimental
Assessment of Value Added to Software Reuse by Ada 95
Technology ESTEC/Contract No.14618/00/NL/MV
which can be obtained from
OBOSS_ported_to_ORK_final_report.pdf.

Sorry to Jeff Carter and Stephan Heinemann and everyone else.

(If you read the page in context, it had actually
been intended that the clause quoted from the
report was specifically just about base priorities
but it is also true that aside from identical base
priorities, Ravenscar allows an active priority to
make a priority level common to more than one task.)

(I may have made the posted
news:slrnbji5jp.jmh.Colin_Paul_Gloster@camac.dcu.ie
by not properly remembering
"WARNING 3.2
ORK users are recommended to assign distinct priorities to all tasks and
                  2
protected objects.

[..]
  2
   ORK allows priorities to be shared -as long as in keeping
withe[with the] ceiling priority protocol- but this is
not a commendable practice unless the task and protected object
population exceeds the allowable range of
priorities. [..]"
from FTP://OpenRavenscar.org/openravenscar/opm2-2.pdf .)