requeue vs requeue with abort - code example pleaseeee
domel
Since few weeks I'm learning ADA. I got stuck on requeue facility. I
canno't completely grasp what the difference between requeue and
requeue with abort is. Please help - some short working code example
would be very appreciated
Dmitry A. Kazakov
> Since few weeks I'm learning ADA. I got stuck on requeue facility. I
> canno't completely grasp what the difference between requeue and
> requeue with abort is.
Use "requeue with abort" when the request is cancelable, i.e. serving it in
its current entry has not changed anything that could get broken if the
request were canceled later. This is the desired behavior.
If serving the request changes some vital things, e.g. you have initiated
its for processing memorizing some things etc, then use "requeue." Don't do
this if you don't need to, because it would make the clients blocked until
the request is serviced (a timed entry will not be able to cancel it).
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Warren
news:7bd3db89-ae9d-4e09...@w2g2000yqb.googlegro
ups.com:
> Hi
> Since few weeks I'm learning ADA. I got stuck ..
Also remember it is "Ada" not "ADA". Otherwise we might assume
you're learning dentistry. ;-)
Warren
Randy Brukardt
news:Xns9E498E732F9FFW...@85.214.73.210...
Or selling milk. Living in Wisconsin, I know that "ADA" means American Dairy
Association.
Which reminds me of a barely relevant story.
Back in RR Software's headay, we moved into offices formerly occupied by the
Wisconsin Milk Marketing Board. While helping to run new network cables, I
discovered that the steel beams in the office were all labeled "ADA of
Wisconsin". Somehow seemed appropriate that we were using that office...
Randy.
Shark8
LOL / Awesome story.
Simon Wright
Veering in the other direction, I found "ada": http://flic.kr/p/8ZNrd5
Dmitry A. Kazakov
> Also remember it is "Ada" not "ADA". Otherwise we might assume
> you're learning dentistry. ;-)
All elder languages had capitalized names: FORTRAN, COBOL, PL, SNOBOL, C.
Two exceptions were Algol and Pascal. But we all know that real programmers
don't use Pascal... (:-))
AdaMagica
abort.
First note:
There is a also a subtle difference between a conditional entry
call and a timed entry call with zero delay (even though 9.7.3(3) says
that
they are equivalent). If the communication time between caller and
callee
is significant, the timed entry call is cancelled at once, even though
the
callee may be ready to accept. The conditional entry call will succeed
because it will not be cancelled before the request reaches the callee
and the open alternatives are examined (a conditional entry call to a
task
running on Voyager will succeed, a timed one will be cancelled).
Imagine two entries E1 and E2 (not necessarily of the same task; the
client calling E1 might even be oblivious of entry E2.
The client performs a timed entry call with E1, which (unknown to the
client is requeued with abort to E2).
There exist several possibilities that the TEC expires before the
requeued
E2 starts as is shown in the following time tables:
A. TEC delay expires before rendezvous begin of E2.
T0: TEC E1 with delay D
T1: rendezvous E1 starts
T2: E1 requeued with abort to E2 - this ends rendezvous, but TEC
of T0 continues
T3=T0+D: clients patience expires
E2 is cancelled - this aborts the TEC (RM 9.7.2(5))
B. TEC delay expires before E1 is requeued to E2, but within
rendezvous
T0: TEC E1 with delay D
T1: rendezvous E1 starts
T2=T0+D: delay expires, but since E1 is executing, rendezvous
continues
T3: requeued with abort to E2 and rendezvous E1 ends
Thus, we now have to distinguish two cases:
(i) E2 is ready for rendezvous:
T3 cont'ed: Entry call E2 is not queued, instead rendezvous E2 starts
immediately, so entry call of T0 is not cancelled.
From the client's point of view, the entry call terminates
normally (because the client is unaware of the requeue).
(ii) E2 is not ready for rendezvous:
T3 cont'ed: Entry call E2 is queued. Since the delay has already
expired at T2, the entry call E2 is immediately cancelled,
i.e. taken out of the queue again.
This is the abortion of the timed entry call at T0
because the call did not start before the expiration
(in fact, it's the call of E2 that did not start before
T2, but the client is unaware of the requeue).
The program below tries to verify this behaviour.
The big delays in the code are just for illustration. In reality,
this would be microseconds.
Imagine the entry E1 is accepted just before the delay expires (it
scrapes
through, so to say). When there is no delay before the requeue, the
task
immediately requeues - but to determine the need to requeue and to do
the
requeue and to terminate the rendezvous need some time,
albeit a tiny amount - just so much that thereafter the delay has
expired.
Now the conditional entry call must fail if E2 is not immediately
ready.
with Ada.Text_IO;
use Ada.Text_IO;
procedure Timed_Entry_Call is
task Server is
entry E1;
end Server;
task Hidden is
entry Start;
entry E2;
end Hidden;
task body Server is
begin
loop
accept E1 do
Put_Line ("E1 accepted");
delay 3.0; -- (1) do some work that takes longer than
client's patience
Put_Line ("E1 requeued");
requeue Hidden.E2 with abort;
end E1;
end loop;
end Server;
task body Hidden is
begin
accept Start;
Put_Line ("E2 ready");
loop
accept E2 do
Put_Line ("E2 accepted");
end E2;
end loop;
end Hidden;
begin
for I in 1 .. 2 loop
Put_Line ("Round" & Integer'Image (I));
select
Server.E1; -- E1 is ready for rendezvous
Put_Line ("E1 done");
or
delay 1.0; -- (2)
Put_Line ("First time aborting because E2 not ready");
Hidden.Start; -- Make E2 ready for second time
end select;
delay 1.0;
New_Line;
end loop;
Put_Line ("Done");
abort Server, Hidden;
end Timed_Entry_Call;
-- Expected result (this is possibility B):
-- Round 1
-- E1 accepted
-- E1 requeued
-- First time aborting because E2 not ready
-- E2 ready
--
-- Round 2
-- E1 accepted
-- E1 requeued
-- E2 accepted
-- E1 done
--
-- Done
This is from some experiments many years ago. I hope it's complete and
works.
Adam Beneschan
wrote:
> On Thu, 9 Dec 2010 19:00:12 +0000 (UTC), Warren wrote:
> > Also remember it is "Ada" not "ADA". Otherwise we might assume
> > you're learning dentistry. ;-)
>
> All elder languages had capitalized names: FORTRAN, COBOL, PL, SNOBOL, C.
> Two exceptions were Algol and Pascal. But we all know that real programmers
> don't use Pascal... (:-))
Wikipedia lists ALGOL as being a capitalized name. (It's short for
ALGOrithmic Language.) Not that they're the final authority on
everything.
-- Adam
Robert A Duff
> There is a also a subtle difference between a conditional entry call
> and a timed entry call with zero delay (even though 9.7.3(3) says that
> they are equivalent).
That can't be right. 9.7.3(3) defines the semantics of conditional
entry call. How can the RM be wrong about what the RM says? ;-)
> ...If the communication time between caller and callee is significant,
> the timed entry call is cancelled at once, even though the callee may
> be ready to accept.
No, for a timed entry call, the call is first "issued", which involves
first checking whether the called task or protected object is ready.
This might take a long time (in your Voyager example). It will
certainly take more than 0.0 seconds, but that doesn't matter -- if the
callee is ready, then the entry call proceeds. It doesn't matter that
it takes a finite amount of time to determine whether the callee is
ready.
Only after finding the callee NOT ready do we think about cancelling
the call.
>...The conditional entry call will succeed because it will not be
>cancelled before the request reaches the callee and the open
>alternatives are examined (a conditional entry call to a task running
>on Voyager will succeed, a timed one will be cancelled).
Right.
So a conditional call behaves the same as a timed call with "delay 0.0".
It doesn't matter whether requeue is involved.
Note that it doesn't matter whether the callee is ready at the time
the conditional or timed call starts -- that is unknown, and unknowable.
I snipped your example, because it doesn't have any conditional
entry calls, nor "delay 0.0" calls, so it's not related to
this equivalence.
- Bob
Warren
news:1hvnr1d2wp3vj$.fnxma3y5...@40tude.net:
> On Thu, 9 Dec 2010 19:00:12 +0000 (UTC), Warren wrote:
>
>> Also remember it is "Ada" not "ADA". Otherwise we might
>> assume you're learning dentistry. ;-)
>
> All elder languages had capitalized names: FORTRAN, COBOL,
> PL, SNOBOL, C. ..
That was once true of acronyms, but not for names. As a name, it
has never been right to fully capitalize Ada.
Why they changed the rule for acronyms, beats me though. I liked
things they way they were. Did capitals get more expensive?
Warren
Adam Beneschan
> Dmitry A. Kazakov expounded innews:1hvnr1d2wp3vj$.fnxma3y5...@40tude.net:
I'm curious---what acronyms are you referring to? Most acronyms I see
are still in upper case. (A few pronounceable acronyms ended up
becoming actual words, such as "radar", but that's an exceptional
case.) But I don't think there's been a rule change...
-- Adam
Simon Wright
In the UK there used to be the National Institute for Health and
Clinical Excellence (in the approval loop for drug use in NHS), =>
NIHCE, pronounced "nice", now spelt Nice ... spit (actually I think it
may be about to be abolished ..)
Peter C. Chapin
> Why they changed the rule for acronyms, beats me though. I liked
> things they way they were. Did capitals get more expensive?
My understanding is that FORTRAN was officially renamed Fortran during
the deliberations that lead to Fortran 90. I could be wrong about this;
I think I picked up this tidbit while I was lurking on
comp.lang.fortran, but I'm sure everything said there is true. :)
Anyway I believe that FORTRAN refers to the pre-Fortran 90 versions of
the language and Fortran refers to all following versions.
Peter
Adam Beneschan
> On 2010-12-10 15:13, Warren wrote:
>
> > Why they changed the rule for acronyms, beats me though. I liked
> > things they way they were. Did capitals get more expensive?
>
> My understanding is that FORTRAN was officially renamed Fortran during
> the deliberations that lead to Fortran 90. I could be wrong about this;
> I think I picked up this tidbit while I was lurking on
> comp.lang.fortran, but I'm sure everything said there is true. :)
Your understanding is consistent with what Wikipedia says. There's no
explanation of *why* the change in case, though. My guess is that
changing it from all-caps to mostly-lower-case in 1990 was, at heart,
a change from proclaiming proudly that one used the language to
whispering it, probably out of embarrassment that people were still
using such ridiculously out-of-date language technology... :) :) :)
-- Adam
AdaMagica
> AdaMagica <christoph.gr...@eurocopter.com> writes:
> > There is a also a subtle difference between a conditional entry call
> > and a timed entry call with zero delay (even though 9.7.3(3) says that
> > they are equivalent).
>
> That can't be right. 9.7.3(3) defines the semantics of conditional
> entry call. How can the RM be wrong about what the RM says? ;-)
Ha, that's funny. This is what one of your collegues at AdaCore
explained (I was a supported customer at that time). And that's also
what I read at several other places IIRC.
And the RM is certainly "wrong" at several places where ACATS defines
what is to be done (e.g. reading numerals via Text_IO from files ;-).
Robert 'Dewar likes to point this out.
Warren
news:604b2e52-cfcb-49d0...@r19g2000prm.googlegr
oups.com:
> On Dec 10, 12:13 pm, Warren <ve3...@gmail.com> wrote:
>> Dmitry A. Kazakov expounded
>> > All elder languages had capitalized names: FORTRAN,
>> > COBOL, PL, SNOBOL, C. ..
>>
>> That was once true of acronyms, but not for names. As a
>> name, it has never been right to fully capitalize Ada.
>>
>> Why they changed the rule for acronyms, beats me though. I
>> liked things they way they were. Did capitals get more
>> expensive?
>
> I'm curious---what acronyms are you referring to? Most
> acronyms I see are still in upper case. (A few
> pronounceable acronyms ended up becoming actual words, such
> as "radar", but that's an exceptional case.) But I don't
> think there's been a rule change...
>
> -- Adam
I believe I first heard about this change in capitalization
from the publisher I worked with at the time (I wrote two
Linux books and one Unix). I just took their word for it,
since they were responsible for the "editing".
The publishers were American (Sams and Queue, which are now
now all part of the same parent company). FORTRAN and COBOL
were originally acronyms and I believe COBOL still is. I also
thought SNOBOL was an acronym but didn't look it up.
The Chicago Book of Style mentions it here.
http://www.chicagomanualofstyle.org/search.epl?
q=acronyms&site=all&client=live&output=xml_no_dtd&proxystylesh
eet=cmosdev&filter=0&search.x=0&search.y=0&search_edition=16
You need a login to see the citation online. My hardcopy is at
home, which I'll check if I still remember.
Warren
Adam Beneschan
> Adam Beneschan expounded innews:604b2e52-cfcb-49d0...@r19g2000prm.googlegr
We happen to have the 13th edition at the office, but that's pretty
old (1982) so I don't know how much use it is. However, I did notice
that there were two separate sections---one had to do with
capitalization of software-related acronyms, and another with acronyms
in general. The section on the latter listed things like UN, NAACP,
NATO, AARP, none of which I've ever seen in anything but all-
capitals. (Except maybe Interpol.) I'm guessing that when you were
asking "why they changed the rules" you were referring only to
software-related or computer-related acronyms. I didn't pick up on
that at first.
I'm interested to see what the Chicago manual says about this. From
what I can gather from Wikipedia, though, capitalization is just plain
inconsistent. FORTRAN officially became spelled Fortran in 1990.
Unix is trademarked as UNIX but is often written as Unix, or sometimes
with the "nix" in small caps. SNOBOL is still all-caps; SnoBol is a
toilet bowl cleaner. SAIL, one of the languages mentioned in the 13th-
edition Chicago Manual, is likewise all-caps. Wikipedia says that
ALGOL is all caps, but that article itself sometimes uses "Algol" with
no explanation for the inconsistency, except (I guess) that you can
expect some inconsistency when you let everybody and their brother
edit your encyclopedia. Wikipedia also says "Lisp" is the correct
spelling, but LISP is sometimes used by authors or vendors, and
there's no explanation of why there's a difference or whether the
spelling changed at some point in time.
-- Adam
-- Adam
Warren
news:67977735-3e49-45bd...@u9g2000pra.googlegro
ups.com:
> On Dec 13, 8:21 am, Warren <ve3...@gmail.com> wrote:
>> Adam Beneschan expounded
>> > On Dec 10, 12:13 pm, Warren <ve3...@gmail.com> wrote:
>> >> Dmitry A. Kazakov expounded
>> >> > All elder languages had capitalized names: FORTRAN,
>> >> > COBOL, PL, SNOBOL, C. ..
>>
>> >> That was once true of acronyms, but not for names. As a
>> >> name, it has never been right to fully capitalize Ada.
>>
>> >> Why they changed the rule for acronyms, beats me
>> >> though. I liked things they way they were. Did capitals
>> >> get more expensive?
>>
>> > I'm curious---what acronyms are you referring to? Most
>> > acronyms I see are still in upper case. (A few
>> > pronounceable acronyms ended up becoming actual words,
>> > such as "radar", but that's an exceptional case.) But I
>> > don't think there's been a rule change...
>>
>> I believe I first heard about this change in
>> capitalization from the publisher I worked with at the
>> time (I wrote two Linux books and one Unix). I just took
>> their word for it, since they were responsible for the
>> "editing".
..
>> You need a login to see the citation online. My hardcopy
>> is at home, which I'll check if I still remember.
>
> We happen to have the 13th edition at the office, but
> that's pretty old (1982) so I don't know how much use it
> is. However, I did notice that there were two separate
> sections---one had to do with capitalization of
> software-related acronyms, and another with acronyms in
..
> I'm interested to see what the Chicago manual says about
> this. From what I can gather from Wikipedia, though,
> capitalization is just plain inconsistent. FORTRAN
> officially became spelled Fortran in 1990. Unix is
> trademarked as UNIX but is often written as Unix, or
> sometimes with the "nix" in small caps. ..
It could be it was primarily "UNIX" vs "Unix" that I ran into
this. The rules may be different once trademarked or perhaps
it was trademarked with that particular capitalization. But my
editor gave me at the time the impression that the rules had
changed.
My 14th edition (1993) doesn't seem to reflect any change of
rules. I also cannot seem to otherwise find signs of it on the
net, unless like you pointed out, it applies only to software
language acronyms. In any case, the rules are many in this
area. ;-)
Warren