Task vs Protected Type

Task vs Protected Type

[Sébastien]

Hi guys,

I would like to understand a sentence of the wikibook.

In the presentation of Task and Protected we can see the following:
-------------------
-- CODE 1
-------------------
   task type Semaphore_Task_Type is
      entry Initialize (N : in Natural);
      entry Wait;
      entry Signal;
   end Semaphore_Task_Type;
   ...
   task body Semaphore_Task_Type is
      Count : Natural;
   begin
      accept Initialize (N : in Natural) do
         Count := N;
      end Initialize;
      loop
         select
            when Count > 0 =>
                accept Wait do
                   Count := Count - 1;
                end Wait;
         or
                accept Signal;
                Count := Count + 1;
         end select;
      end loop;
   end Semaphore_Task_Type;

-------------------
-- CODE 2
-------------------
   protected type Semaphore_Protected_Type is
      procedure Initialize (N : in Natural);
      entry Wait;
      procedure Signal;
   private
      Count : Natural := 0;
   end Semaphore_Protected_Type;
   ...
   protected body Semaphore_Protected_Type is
      procedure Initialize (N : in Natural) is
      begin
         Count := N;
      end Initialize;
      entry Wait
         when Count > 0 is
      begin
         Count := Count - 1;
      end Wait;
      procedure Signal is
      begin
         Count := Count + 1;
      end Signal;
   end Semaphore_Protected_Type;


Ok the two codes provides the same functionality but obviously not in 
the same way. In the first one, a thread is dedicated to manage the 
semaphore. In the second one, this is a protected type with exclusive 
mutex on entry and procedure and absolutly no thread implementation (as 
far as I understood internal mechanism of protected type)

The first one has the advantage to force the user to Initialize the task 
because of the first entry, but there is no such mechanism in the 
protected type.

So in the wikibook, there is this sentence:
"Alternatively, semaphore functionality can be provided by a protected 
object, with major efficiency gains."

This is between the two codes, letting the reader (me at least) 
understand protected type is a better approach, but I can't understand why.

For example, you have a web application and want to develop an object 
pool. You could use one of both example, since it's the same purpose 
with some GetObject and ReleaseObject enties/procedure in a task or in a 
protected. But which one is the better approach?

Thanks very much.
Sebastien

Re: Task vs Protected Type

[Dmitry A. Kazakov]

On Fri, 30 May 2008 14:12:49 +0000, in comp.lang.ada you wrote:

> I would like to understand a sentence of the wikibook.
[...] 
> The first one has the advantage to force the user to Initialize the task 
> because of the first entry, but there is no such mechanism in the 
> protected type.

Of course there is many. For example:

   protected type Semaphore_Protected_Type (N : Natural) is
      ...
   private
      Count : Natural := N;
   end Semaphore_Protected_Type;

> So in the wikibook, there is this sentence:
> "Alternatively, semaphore functionality can be provided by a protected 
> object, with major efficiency gains."
> 
> This is between the two codes, letting the reader (me at least) 
> understand protected type is a better approach, but I can't understand why.

It is sometimes better, because seizing a semaphore implemented by a
protected object does not require context switching, as it can accomplished
on the caller's context. A rendezvous with the semaphore's monitor task
would usually require switching the context twice.

> For example, you have a web application and want to develop an object 
> pool. You could use one of both example, since it's the same purpose 
> with some GetObject and ReleaseObject enties/procedure in a task or in a 
> protected. But which one is the better approach?

Neither. It is a bad idea to use tasks for implementation of low-level
synchronization primitives (like semaphores). Your web application would
probably do much more things than just locking. Instead of Wait, you would
likely have something like Service (Object), which is more like a
transaction. Because the time required for handling higher level requests
is sufficiently greater than mere switching contexts, the difference might
become negligible. At the same time protected objects tend to be too
low-level. Further, protected actions shall be very short. This requirement
forces a very heavy design, when you have to do some prologue as a
protected action, continue work outside it, and complete it again as a
protected action again. Such things, and semaphore is a typical example of,
are exposed to various nasty problems.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Task vs Protected Type

[Jean-Pierre Rosen]

S�bastien a �crit :
[...]

> The first one has the advantage to force the user to Initialize the task 
> because of the first entry, but there is no such mechanism in the 
> protected type.
The value of the mutex is given by the discriminant, no initialization 
needed.

> So in the wikibook, there is this sentence:
> "Alternatively, semaphore functionality can be provided by a protected 
> object, with major efficiency gains."
This is likely true on a bare board, I would be more careful when 
running under a conventional OS.

> For example, you have a web application and want to develop an object 
> pool. You could use one of both example, since it's the same purpose 
> with some GetObject and ReleaseObject enties/procedure in a task or in a 
> protected. But which one is the better approach?
> 
A task is a high level structure, a protected type is a low level 
synchronization mechanism.

However, implementing a low level mechanism (like a semaphore) with a 
task is certainly abstraction inversion. OTOH, if you use rendezvous, 
you can avoid semaphores altogether (in general of course, YMMV).

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Task vs Protected Type

[Sébastien]

>    protected type Semaphore_Protected_Type (N : Natural) is
>       ...
>    private
>       Count : Natural := N;
>    end Semaphore_Protected_Type;

I see, using a discriminant type does not require an initialization. I 
must admit I still have difficulties to think discriminant type while I 
understand quite well how powerful they are.

> Neither. It is a bad idea to use tasks for implementation of low-level
> synchronization primitives (like semaphores). Your web application would
> probably do much more things than just locking. Instead of Wait, you would
> likely have something like Service (Object), which is more like a
> transaction. Because the time required for handling higher level requests
> is sufficiently greater than mere switching contexts, the difference might
> become negligible. At the same time protected objects tend to be too
> low-level. Further, protected actions shall be very short. This requirement
> forces a very heavy design, when you have to do some prologue as a
> protected action, continue work outside it, and complete it again as a
> protected action again. Such things, and semaphore is a typical example of,
> are exposed to various nasty problems.

Ok thanks for the explanations, I understand very well and I'm able to 
make the comparisons with what I'm used to meet in C/C++.

Sebastien

Re: Task vs Protected Type

[Jeffrey R. Carter]

S�bastien wrote:
> 
> For example, you have a web application and want to develop an object 
> pool. You could use one of both example, since it's the same purpose 
> with some GetObject and ReleaseObject enties/procedure in a task or in a 
> protected. But which one is the better approach?

For data protection, a protected object is usually better (a semaphore protects 
its state information). A custom protected object is usually better than a 
semaphore, too. When you must use a semaphore, a safe semaphore using 
controlled-type initialization and finalization is usually better than a simple 
semaphore.

-- 
Jeff Carter
"Ah, go away or I'll kill ya."
Never Give a Sucker an Even Break
100