Re: Private or public task ?

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

On 8 fév, 18:28, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> 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.
>
> 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)
Protected types was most the subject of another thread, but as you
talked about it here : I don't understand why you've protected
operation (I suppose you were talking about procedures, not entries)
are not themselves blocking. They grant exclusive read-write access
and ensure there is no race. So if another task is currently running
the procedure of a protected type, another task cannot enter this
procedure if it was to do so and a task switch occurs at the same
time.

Or is it guaranteed that no task switch can occurs when a task is
actually in a procedure of a protected type ? Is the task switch
delayed in such a circumstance ?

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.