RE: Penalty of calling a protected operation or task-entry.

RE: Penalty of calling a protected operation or task-entry.

[Beard, Frank Randolph CIV]

-----Original Message-----
From: Frank

> Can someone point me to some literature or elaborate on this penalty?
Oops!  Skipped this question.

Section 9.4 of that Ada 95 Rationale goes into the benefits and reasons
behind (rationale) asynchronous transfer of control, as implemented 
with protected types/objects.

> Frank

Frank

Penalty of calling a protected operation or task-entry.

[Frank]

Hi!

GNAT 3.15p (WindowsXPProfessional / Linux'es)
--------
As I have understood there is a time-penalty when calling a protected
operation or task-entry. Im thinking about adminstrative cost
of the call, not loss of parallell'ism.

My situation is the following:
If I have a protected type that has two operation one "read" and one
"write". These are called by different tasks.
The "write" operation is called very seldom, but the "read" is called very
often.

Is there some approach to remove penalty from the "read" operation?


--------
Can someone point me to some literature or elaborate on this penalty?

Frank

Re: Penalty of calling a protected operation or task-entry.

[tmoran]

>As I have understood there is a time-penalty when calling a protected
>operation or task-entry. Im thinking about adminstrative cost
  Have you profiled your program and found that the protected
operations are the bottleneck?

>Is there some approach to remove penalty from the "read" operation?
  If another task is doing a Write, then Read will have to suffer the
penalty of waiting.  If not, then it depends on how efficient is your
particular system's implementation.

Re: Penalty of calling a protected operation or task-entry.

[Steve]

Make the read operations use protected functions, they can happen
concurrently (see: LRM 9.5.1).  You will still have some penalty for
protected procedures since they are mutually exclusive.

Steve
(The Duck)

"Frank" <franjoe@frisurf.no> wrote in message
news:8cGcb.25659$os2.355577@news2.e.nsc.no...
> Hi!
>
> GNAT 3.15p (WindowsXPProfessional / Linux'es)
> --------
> As I have understood there is a time-penalty when calling a protected
> operation or task-entry. Im thinking about adminstrative cost
> of the call, not loss of parallell'ism.
>
> My situation is the following:
> If I have a protected type that has two operation one "read" and one
> "write". These are called by different tasks.
> The "write" operation is called very seldom, but the "read" is called very
> often.
>
> Is there some approach to remove penalty from the "read" operation?
>
>
> --------
> Can someone point me to some literature or elaborate on this penalty?
>
> Frank
>
>
>

Re: Penalty of calling a protected operation or task-entry.

[Jeffrey Carter]

Steve wrote:

> Make the read operations use protected functions, they can happen
> concurrently (see: LRM 9.5.1).  You will still have some penalty for
> protected procedures since they are mutually exclusive.

The OP referred specifically to GNAT 3.15p. IIRC, all protected 
operations obtain a mutex before proceeding in the GNAT implementation, 
so GNAT does not use this approach.

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20

RE: Penalty of calling a protected operation or task-entry.

[Beard, Frank Randolph CIV]

-----Original Message-----
From: tmoran@acm.org 

>> As I have understood there is a time-penalty when calling a protected
>> operation or task-entry. Im thinking about adminstrative cost
>   Have you profiled your program and found that the protected
> operations are the bottleneck?

>> Is there some approach to remove penalty from the "read" operation?
>   If another task is doing a Write, then Read will have to suffer the
> penalty of waiting.  If not, then it depends on how efficient is your
> particular system's implementation.

To add to what Tom said, we've never had the task-entry rendezvous
become enough of a time-penalty to cause us any problems.  Protected
types were partially created/implemented to alleviate the "penalty"
of the rendezvous.  So use a protected type if it fits your design.

Besides, what's your alternative if you need protected operations.
Protected types are at least as fast, or faster, than going to an
OS level semaphore.

Frank