* Re: Penalty of calling a protected operation or task-entry.
2003-09-26 3:09 Frank
@ 2003-09-25 19:30 ` tmoran
2003-09-26 2:59 ` Steve
1 sibling, 0 replies; 6+ messages in thread
From: tmoran @ 2003-09-25 19:30 UTC (permalink / raw)
>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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Penalty of calling a protected operation or task-entry.
@ 2003-09-25 19:54 Beard, Frank Randolph CIV
0 siblings, 0 replies; 6+ messages in thread
From: Beard, Frank Randolph CIV @ 2003-09-25 19:54 UTC (permalink / raw)
To: comp.lang.ada
-----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Penalty of calling a protected operation or task-entry.
@ 2003-09-25 20:17 Beard, Frank Randolph CIV
0 siblings, 0 replies; 6+ messages in thread
From: Beard, Frank Randolph CIV @ 2003-09-25 20:17 UTC (permalink / raw)
To: Frank, comp.lang.ada
-----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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Penalty of calling a protected operation or task-entry.
2003-09-26 3:09 Frank
2003-09-25 19:30 ` tmoran
@ 2003-09-26 2:59 ` Steve
2003-09-26 18:00 ` Jeffrey Carter
1 sibling, 1 reply; 6+ messages in thread
From: Steve @ 2003-09-26 2:59 UTC (permalink / raw)
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
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Penalty of calling a protected operation or task-entry.
@ 2003-09-26 3:09 Frank
2003-09-25 19:30 ` tmoran
2003-09-26 2:59 ` Steve
0 siblings, 2 replies; 6+ messages in thread
From: Frank @ 2003-09-26 3:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Penalty of calling a protected operation or task-entry.
2003-09-26 2:59 ` Steve
@ 2003-09-26 18:00 ` Jeffrey Carter
0 siblings, 0 replies; 6+ messages in thread
From: Jeffrey Carter @ 2003-09-26 18:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-09-26 18:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-25 19:54 Penalty of calling a protected operation or task-entry Beard, Frank Randolph CIV
-- strict thread matches above, loose matches on Subject: below --
2003-09-25 20:17 Beard, Frank Randolph CIV
2003-09-26 3:09 Frank
2003-09-25 19:30 ` tmoran
2003-09-26 2:59 ` Steve
2003-09-26 18:00 ` Jeffrey Carter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox