Re: Private or public task ?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@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