Tasking, protected objects, Ada 95 RM

Tasking, protected objects, Ada 95 RM

[ldb]

I have a bit of tasking code that works pretty good. I'm still
stress-testing it to put the stamp of approval on it, and have come
across somethign that's a bit alarming.

My code is meant to do a big parallel computation in a multithreaded
fashion. I have a big buffer of data chunks to be processed, and a
bunch of tasks feeding off that buffer processing data. Simple enough.

During the buffers initialization, it has an entry call for "connect"
where tasks can connect and it can keep track of how many tasks are
currently "reading" from it. These tasks can then do "get_chunk".
Pretty simple, so far so good.

During the Task initilization, they have an "accept" statement from the
main program that will point them to a buffer from which to read data.
Inside this "accept" statement, they make a call to the buffer.connect
function.

This, in essence, is an atmoic "accept" statement making a calling to a
protected types "entry" statement. This leads to the following alarming
statement in the ada 95 RM:

From: http://www.grammatech.com/rm95html-1.0/rm9x-09-05-01.html
> During a protected action, it is a bounded error to invoke an operation that is potentially blocking.

It goes on to define potentially blocking actions as, of course, an
entry_call. Now, I've never had my code raise a bounded error or a
program error. Here is a quick synopsis of my questions:

1) Am I misunderstanding this particular part of the manual, and it, in
fact, doesn't apply to my code?
2) Should I be worried?
3) Will -gnatp prevent this exception from being raised?

Re: Tasking, protected objects, Ada 95 RM

[Ed Falis]

ldb wrote:

> During the Task initilization, they have an "accept" statement from
> the
> main program that will point them to a buffer from which to read data.
> Inside this "accept" statement, they make a call to the buffer.connect
> function.
>
> This, in essence, is an atmoic "accept" statement making a calling to
> a
> protected types "entry" statement. This leads to the following
> alarming
> statement in the ada 95 RM:
>
> From: http://www.grammatech.com/rm95html-1.0/rm9x-09-05-01.html
>> During a protected action, it is a bounded error to invoke an
> operation that is potentially blocking.

An accept statement is not a protected action in the technical jargon of
the RM.  So calling connect from there is not potentially blocking.  Now
if you were to call an entry from within connect, that would be a
different story.

- Ed

Re: Tasking, protected objects, Ada 95 RM

[Ed Falis]

Ed Falis wrote:

> An accept statement is not a protected action in the technical jargon
> of
> the RM.  So calling connect from there is not potentially blocking.

Sorry, it is "potentially blocking" but not in a manner that is
meaningful in the context of the quote you gave from the RM - it is not
a bounded error in this case.

Re: Tasking, protected objects, Ada 95 RM

[Georg Bauhaus]

On Tue, 2006-07-18 at 08:09 -0700, ldb wrote:


> It goes on to define potentially blocking actions as, of course, an
> entry_call. Now, I've never had my code raise a bounded error or a
> program error. Here is a quick synopsis of my questions:

The last sentence sounds as if you might have understood a bounded
error to be an exception. So just in case, a bounded error is
another technical term (LRM 1.1.5(7)), not an exception.

2c,
-- Georg 

Re: Tasking, protected objects, Ada 95 RM

[Randy Brukardt]

"ldb" <ldb_nospam@hotmail.com> wrote in message
news:1153235397.700369.134780@35g2000cwc.googlegroups.com...
...
> It goes on to define potentially blocking actions as, of course, an
> entry_call. Now, I've never had my code raise a bounded error or a
> program error. Here is a quick synopsis of my questions:
>
> 1) Am I misunderstanding this particular part of the manual, and it, in
> fact, doesn't apply to my code?

Mostly likely. You've misunderstood the meaning of "protected action".
Loosely, that's the time when your program is executing *inside* of a
protected object (executing the code of a protected object). Your
description suggests you are not making an entry call from inside of a
protected object.

> 2) Should I be worried?

No.

> 3) Will -gnatp prevent this exception from being raised?

A "bounded error" is not necessarily an exception. It's actually better in
this case if it *is* an exception, because it indicates a fundamental design
flaw in your program. There is (in Ada 2005) a pragma Detect_Blocking for
this purpose. I think the vast majority of (portable) Ada programs should
include this pragma (the check is not expensive, and the results if the
error occurs are very dangerous and likely to be fatal).

You really, really, really do not want this error to go undetected. If an
exception is raised, you can find the cause and fix it (and even recover
from it in a limited way). If the error is *not* detected, the most likely
result is that your program will deadlock (the protected object will be
locked and no other task can get into it). Another possible result is the
loss of mutual exclusion for the protected object (which means it is highly
likely that the code of the PO will fail because of assumption failure).
Both of the latter are far harder to debug than getting an exception from
the bad operation!! Do not fear detection of errors!

                        Randy.

Re: Tasking, protected objects, Ada 95 RM

[ldb]

Thanks everyone of the input. And thanks for the heads-up about
Pragma(Detect_Blocking). Yes, it is true that I am not calling a
blocking operation from a protected object.. after carefully reading
the RM95 manual and looking up a bunch of cross references, I was able
to convince myself that what I am doing is perfectly acceptable... and
you all appear to be in accordance with that, which is good.

Re: Tasking, protected objects, Ada 95 RM

[Anh Vo]

> >>> Ed Falis <falis@verizon.net> 7/18/2006 8:30:18 AM >>>
> Ed Falis wrote:

> > An accept statement is not a protected action in the technical
jargon
> > of
> > the RM.  So calling connect from there is not potentially
blocking.

> Sorry, it is "potentially blocking" but not in a manner that is
> meaningful in the context of the quote you gave from the RM - it is
not
> a bounded error in this case.

Tasking is always my favorite interest. In fact, this is a cool,
advanced and complex stuff. Beside Ed's answer, I would suggest that
your codes be posted, if it is not proprietary. This makes the
discussion more precise and no misunderstanding :-)

AV