From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5d05ccde5cefb836
X-Google-Attributes: gid103376,public
From: Mats Weber <Mats.Weber@elca-matrix.ch>
Subject: Re: Blocking protected ops (was: Tasks and C/C++ code)
Date: 1998/11/25
Message-ID: <365BE117.59209A5@elca-matrix.ch>#1/1
X-Deja-AN: 415482926
Content-Transfer-Encoding: 7bit
References: <364702E5.F6987321@hiwaay.net> <729ndu$jfo$1@nnrp1.dejanews.com>
 <72b35b$pll$1@nnrp1.dejanews.com> <87btm52jwl.fsf@zaphod.enst.fr>
 <3654746F.3C297E56@elca-matrix.ch> <87k90qunxl.fsf@zaphod.enst.fr>
 <36599BE3.BA30555B@elca-matrix.ch> <3659b3a8.386623@news.pacbell.net>
 <365AD980.5729FCD8@elca-matrix.ch> <EACHUS.98Nov24143823@spectre.mitre.org>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: ELCA Matrix SA
Mime-Version: 1.0
Reply-To: Mats.Weber@elca-matrix.ch
Newsgroups: comp.lang.ada
Date: 1998-11-25T00:00:00+00:00
List-Id: <comp.lang.ada>

"Robert I. Eachus" wrote:
> 
> In article <365AD980.5729FCD8@elca-matrix.ch> Mats Weber <Mats.Weber@elca-matrix.ch> writes:
> 
>  > Anyway, the question remains: is it legal for a protected body to call
>  > some imported subprogram that could block (in the pthreads sense of the
>  > term) ?
> 
>     You quoted the answer yourself, it is a bounded error per
> 9.5.1(8&16) seem to cover it completely.

I don't think so. Look closely at 9.5.1(16&18). Subprograms imported
with pragma Import are not covered.

>  > Does someone know why the rule 9.5.1(8-18) is there at all ?
> 
>     To rigorously define the conditions where you should allow for
> the possibility of deadlocks and other blocking problems.  Some
> deadlocks (or worse, race conditions) can't be ruled out, because they
> are inherent in the nature of the beast.  Subclause 9.5.1 limits the
> number of programs that are potentially affected by this, in part by
> strongly encouraging programmers not to do that!

I still don't see why an accept statement is allowed to contain a
potentially blocking call, but a protected procedure is not.

To me, this looks a little like incorrect order dependences in Ada 83,
where the compiler was allowed to raise Program_Error if it detected
one, but it is generally not able to detect them. How could a protected
body detect that a blocking operation is being called, if that operation
was imported ?

>     This is a perfect example.  Most compilers will generate code to
> call gethostbyname within a protected subprogram, but most users will
> be encouraged by the RM to do it right.  In this case really right is
> probably to put the potentially offensive call in a task (or protected
> object) that encapsulates all potentially locking OS calls. [...]

I think this should be a task, but _not_ a protected object. If you want
to use a protected object and not call gethostbyname from within the
protected body, you have to make two calls:

   Semaphore.Seize;  -- Semaphore is a protected object
   gethostbyname();
   Semaphore.Release;

which seems silly because you need two protected calls.