Re: Easily-Read C++?

[jmills@ccrf-news.gatech.edu (John M. Mills)]

WARNING: long-winded response follows:

In article <37en3i$sn7@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>John (Mills), I assume that you see from my previous post that the question
>I posed is indeed a well defined one. I assumed that we are dealing with
>a volatile variable here, since otherwise all bets are off of course in
>the presence of concurrent access), but assuming the variable is atomic in
>the Ada sense (something you can't specify in C, but you can in practice
>count on, given a reasonable guess about the hardware and the compiler), 
>there is still a fundamental question: how many reads are you allowed,
>only 1, or are you allowed 2?

DISCLAIMER:  I am not a qualified language lawyer in either C or Ada!

Robert --

I apologize for missing the thrust of your posting.  I understand that C
defines the precedence, but not necessarily the order of evaluation of
elements of an r-value expression, so that implementation dependencies may
be encountered in using the unary ++ and -- pre- and post-fix operators.

Thus, I would not use an expression such as:
   y = ++x + x;

This is independent of the issue of parallel processes, whether interrupt-
activated or threaded.  I do not know whether judicious use of parentheses
can eliminate possible dependencies, either.

If the variable is declared 'volatile,' I would expect the compiler to read
the storage location each time I used the variable name in an expression or
control statement.  I would expect this is in Ada or C.  I don't know if this
removes all ambiguity in the case, for example, of a pointer-referenced
access.  (See DISCLAIMER.)

Were you suggesting that one thread of C code might intercede during the
evaluation of an expression on another thread?  Does Ada guarantee this
would never happen?  I am unsure what distinction you want to make here.
I took a quick look at the LRM index, but didn't turn up 'atomic.' Please
clue me on that.  Thanks.

We often use common variables and memory-mapped I/O in Ada to communicate
between tasks and between independent programs running on multiple processors
on a common VME bus.  We have had task-to-task interference in such cases,
on one processor.  In that case we could have used the rendezvous mechanism
to arbitrate the activity, but instead we created a lock/unlock package
which seems to work well.  I couldn't guarantee it immune to deadlock, but
it _will_ prevent invisible alteration of data by a competing task.  This could
be rewritten and used in C -- there's nothing special in our Ada.

I am quite interested in this question, as we encounter competitive access
fairly often in our designs.  We have taken the proverbial approach of
porcupines to sexual intercourse: we are very, _very_ careful! I have been
burned many times by this type of contention, and the most recent case
was in Ada.

I may still be missing the point.  If so, please excuse me and feel free to
try another tack -- maybe e-mail, since I'm rather obtuse.

Regards --jmm--

-- 
John M. Mills, SRE -- john.m.mills@gtri.gatech.edu -- (404)528-3258 (voice)
   Georgia Tech/ GTRI/ SDL, 7220 Richardson Rd., Smyrna, GA 30080
   "Well, I'm an Assistant Regurgitation Engineer --
     but I should make Senior R.E. next year" _The_Far_Side_, G. Larson