From: Alex R. Mosteo on
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
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
"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
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
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