Private or public task ?
in [ADA]
|
Prev: About the F-22 software bug
Next: Tue Feb 23 Seminar - Ada and SPARK for education and research
From: mkasun on 9 Feb 2010 18:38 On Feb 5, 4:38 pm, "Jeffrey R. Carter" <spam.jrcarter....(a)spam.acm.org> wrote: > Hibou57 (Yannick Duch ne) wrote: > > > So I wanted to solve this, and added a protected object providing an > > Put procedure which was displaying the same message, all three > > statement in an atomic procedure. > > Technically this is a bounded error: Ada.Text_IO.Put* operations are potentially > blocking, and should not be called from a protected operation. > > > Later, I advised the task may terminates while some potential clients > > may still be alive, or even the task may terminates before any client > > had time to make any first request. > > This should not happen. Did you actually experience this? > > -- > Jeff Carter > "He didn't get that nose from playing ping-pong." > Never Give a Sucker an Even Break > 110 Why do people insist that Ada.Text_IO.Put routines are potentially blocking. From the ARM Discussion: {AI95-00178-01} Any subprogram in a language-defined input- output package that has a file parameter or result or operates on a default file is considered to manipulate a file. An instance of a language-defined input-output generic package provides subprograms that are covered by this rule. The only subprograms in language- defined input-output packages not covered by this rule (and thus not potentially blocking) are the Get and Put routines that take string parameters defined in the packages nested in Text_IO.
From: Robert A Duff on 9 Feb 2010 18:51 "mkasun(a)gmail.com" <mkasun(a)gmail.com> writes: > Why do people insist that Ada.Text_IO.Put routines are potentially > blocking. Because they're talking about the ones that operate on files, which are the commonly-used ones. If you say: Ada.Text_IO.Put_Line("Hello, world."); in a protected procedure, that's wrong. GNAT will often let you get away with it, but it's still wrong, because Put_Line is potentially blocking. Yes, as you quote below, the Get/Put that do parsing/formatting on strings are not blocking, as you would expect. But these are rarely used, so people forget about them. > From the ARM > > Discussion: {AI95-00178-01} Any subprogram in a language-defined input- > output package that has a file parameter or result or operates on a > default file is considered to manipulate a file. An instance of a > language-defined input-output generic package provides subprograms > that are covered by this rule. The only subprograms in language- > defined input-output packages not covered by this rule (and thus not > potentially blocking) are the Get and Put routines that take string > parameters defined in the packages nested in Text_IO. - Bob
From: Jeffrey R. Carter on 9 Feb 2010 19:01 mkasun(a)gmail.com wrote: > > Why do people insist that Ada.Text_IO.Put routines are potentially > blocking. > > From the ARM > > Discussion: {AI95-00178-01} Any subprogram in a language-defined input- > output package that has a file parameter or result or operates on a > default file is considered to manipulate a file. An instance of a > language-defined input-output generic package provides subprograms > that are covered by this rule. The only subprograms in language- > defined input-output packages not covered by this rule (and thus not > potentially blocking) are the Get and Put routines that take string > parameters defined in the packages nested in Text_IO. Probably because of ARM 9.5.1: "the subprograms of the language-defined input-output packages that manipulate files (implicitly or explicitly) are potentially blocking." -- Jeff Carter "My mind is aglow with whirling, transient nodes of thought, careening through a cosmic vapor of invention." Blazing Saddles 85
From: Maciej Sobczak on 10 Feb 2010 03:17 On 9 Lut, 15:26, Jean-Pierre Rosen <ro...(a)adalog.fr> wrote: > There are two kinds of blockings: bounded and unbounded. The idea is > that when computing a time budget, you can account for bounded > blockings, but not unbounded ones. > The "potentially blocking" phrase should be understood as really meaning > unbounded. Well, I know what you try to convey, but there are traps: delay Some_Static_Constant; Is it bounded or unbounded? As far as WCET (or any other time-based analysis) goes, the above can be accounted for statically. Still, it is a no-no within any protected operation. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada
From: Hibou57 (Yannick Duchêne) on 10 Feb 2010 03:29
On 10 fév, 09:17, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > > There are two kinds of blockings: bounded and unbounded. The idea is > > that when computing a time budget, you can account for bounded > > blockings, but not unbounded ones. > > The "potentially blocking" phrase should be understood as really meaning > > unbounded. > > Well, I know what you try to convey, but there are traps: > > delay Some_Static_Constant; > > Is it bounded or unbounded? > > As far as WCET (or any other time-based analysis) goes, the above can > be accounted for statically. Still, it is a no-no within any protected > operation. Interesting enigma I would say Bounded, as it is predictable. .... as long as the delay is short, otherwise it will break the other rule stating that a protected operation should be fast to execute. If I try to have a delay X.Y in a protected operation, GNAT just warns me potentially blocking operation in protected operation , while the program is still compiled. You've said it is a no-no within any protected : do you get a compilation error when you do the same ? I've not seen anything in the Rationale nor in the ARM which explicitly disallow it anyway (but as these are long pages I should later read again, I may have miss it). |