Re: Reprise: 'in out' parameters for functions

["Robert I. Eachus" <rieachus@comcast.net>]

Wojtek Narczynski wrote:

> Or the simplest possible: two protected counters, try to get the sum
> atomically.

Since this is trivial, I can only assume that you have two protected 
counters with no support for external locking in mind.  Actually, you 
can even do that, by having one counter have a Sum operation that calls 
the other.

The fact that two arbitrary counters cannot be added atomically in all 
cases is a feature of the real world, not of Ada. Certainly any two 
counters that can be managed with a P,V protocol can be added 
atomically.  It is also possible if only one counter has P, V support.

However, this whole subject is probably silly.  If I give you a total 
outside of any locking which is guaranteed to have been correct at some 
point in the past, how do you know whether it was atomic or not?  The 
answer has to be that it was possible to increment both counters with an 
atomic operation. (For example, any odd sum could be invalid.)  But once 
we postulate atomic joint increments, atomic sums are obviously also 
possible.

Reminds me of a lot of improvement requests for Ada 9X.  "We want to do 
such and such."

"Well, here is a simple example of how to do it in current Ada."

"Oh, but our software development plan doesn't allow us to use 
Unchecked_Conversion."

Well, fix your bloody SDP, you nit!

Hmm. It sounds harsh said like that, but what they wanted to do was 
exactly the reason that their SDP forbid Unchecked_Conversion.  Whether 
the SDP or the guy writing the improvement request was "right" in the 
context of a particular project was irrelevant to the design of Ada 9X. 
  Ada, as designed, allowed SDPs to easily allow or forbid use of some 
features.  (Right now the best example of this is the SPARK checker that 
forbids exceptions and dynamic allocations.)  The intent was exactly to 
allow projects to "tailor" the subset they used.  (I just ran into 
another CS professor who didn't understand that the Ada 83 "no subsets" 
rule was for validated compilers, not for projects. Sigh.)

Back to the example that started all this.  Either it "makes sense" to 
atomically lock both counters, or it doesn't.  This is a design 
criteria, and will affect how the counters are implemented.  If a later 
change adds this requirement, you may have to change the implementation 
of the counters.  Said like that, it sounds so _obvious_.
-- 

                                           Robert I. Eachus

"The terrorist enemy holds no territory, defends no population, is 
unconstrained by rules of warfare, and respects no law of morality. Such 
an enemy cannot be deterred, contained, appeased or negotiated with. It 
can only be destroyed--and that, ladies and gentlemen, is the business 
at hand."  -- Dick Cheney