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: Alex R. Mosteo on 9 Feb 2010 09:44 Maciej Sobczak wrote: > On 5 Lut, 22:53, Hibou57 (Yannick Duchêne) <yannick_duch...(a)yahoo.fr> > wrote: > >> I did not ever suspected such a requirement. Transitive blocking is >> not allowed ? > > As far as I understand, there is a careful wording around this subject > so that formally speaking protected operations (except for entries) > are not themselves "blocking". So, for example, you can call protected > operations from other protected operations. And this makes sense: if you don't allow anything blocking inside a protected procedure, it follows that the procedure is itself non-blocking :) Entries, on the other hand, are blocking... because you don't know if you'll be blocked on the entry conditional. This is true even for non-conditional entries, I think, because of possible requeues. Alex. > The operations that are considered to be blocking in this context are > delay statements, entry calls, select statements and... I/O > operations. These cannot be called from protected operations. > > (I'm sure somebody will correct me if I'm off tracks) > >> So, if blocking operation are not allowed from a protected type, >> clients of a given operation have to know it weither or not it's >> potentially blocking, > > That would be nice, yes. But be careful, this approach might blow up > the language. What about exception specifications? And so on. > > But: see RavenSPARK. > > The problem with blocking in particular is that there is no way to > verify whether imported subprograms (from C libraries, for example) > are blocking. You can import I/O operations from C libraries and there > is no way to verify what they do. > > -- > Maciej Sobczak * www.msobczak.com * www.inspirel.com > > Database Access Library for Ada: www.inspirel.com/soci-ada
From: Jean-Pierre Rosen on 9 Feb 2010 09:26 Hibou57 (Yannick Duch�ne) a �crit : > [...] > Sure a procedure of a protected type or object should be short and > quick to execute, but it seems to still remains potentially blocking. 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. protected procedures are bounded, because if you know the processing time and the maximum number of tasks waiting, you know the WCET of the procedure. Entries are unbounded, because they depend on a guard whose condition can be anything. The "potentially blocking" phrase should be understood as really meaning unbounded. This all boils down to: "an operation with a bounded execution time is not allowed to call an operation with an unbounded execution time". Makes more sense? -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Robert A Duff on 9 Feb 2010 10:20 "Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)yahoo.fr> writes: > Let temporarily suppose so. But remains another wolf in the wood : > what if the application is running in a multiprocessors environment > and its thread are not executed on the same CPU ? If one task on CPU#1 > was to enter a procedure of a protected object while a task on CPU#2 > is actually running a procedure on the same protected object, then, > the task running on CPU#1 must be delayed, and thus, the procedure is > blocking. > > Sure a procedure of a protected type or object should be short and > quick to execute, but it seems to still remains potentially blocking. You should read all the stuff in the Real Time annex about priorities and ceilings and policies and whatnot. No, protected procedures and functions are not potentially blocking. In your multiprocessor example, task#1 cannot procede into the protected procedure until task#2 lets go of it, but that's not blocking. No lower-or-equal priority task can preempt task#1. One possible implementation is that task#1 spins on the lock, which is OK because you made sure your protected procedure executes in a short bounded time. This all depends on using the right real-time policy. Other policies are possible -- and likely, when running on top of a desktop OS. Protected entries, on the other hand, are potentially blocking, because they put the task to sleep for an arbitrarily long time (until the barrier becomes True). - Bob
From: Hibou57 (Yannick Duchêne) on 9 Feb 2010 13:17 On 9 fév, 15:26, Jean-Pierre Rosen <ro...(a)adalog.fr> wrote: > protected procedures are bounded, because if you know the processing > time and the maximum number of tasks waiting, you know the WCET of the > procedure. Entries are unbounded, because they depend on a guard whose > condition can be anything. > > The "potentially blocking" phrase should be understood as really meaning > unbounded. This all boils down to: "an operation with a bounded > execution time is not allowed to call an operation with an unbounded > execution time". > > Makes more sense? Yes, more sense. Bounded/Unbounded execution-time is better expressive. Side note. For peoples who like me didn't knew what is WCET : its "Worst Case Execution Time" (dixit Wikipedia).
From: Hibou57 (Yannick Duchêne) on 9 Feb 2010 13:26
On 9 fév, 16:20, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > You should read all the stuff in the Real Time annex about priorities > and ceilings and policies and whatnot. > > No, protected procedures and functions are not potentially blocking. The misunderstanding was because I was misled on the meaning of "blocking". Jean-Pierre's words changed the situation (see his post). > In your multiprocessor example, task#1 cannot procede > into the protected procedure until task#2 lets go > of it, but that's not blocking. No lower-or-equal priority > task can preempt task#1. One possible implementation is > that task#1 spins on the lock, which is OK because you > made sure your protected procedure executes in a short > bounded time. I've later learned today about spin, but I still have to learn more about it (that's an other area). > Protected entries, on the other hand, are potentially blocking, > because they put the task to sleep for an arbitrarily long time > (until the barrier becomes True). Unbounded |