comp.lang.ada
 help / color / mirror / Atom feed
From: widget!jgg@uunet.uu.net  (Xmiester)
Subject: Re: Ada / X / Motif multi-tasking issues
Date: 13 Apr 92 21:54:34 GMT	[thread overview]
Message-ID: <1992Apr13.215434.8973@widget!uunet.uu.net> (raw)

response to daves@assip.csasyd.oz.au (David Smart) innaccurately reverse-flames
:

[irrelevant nonsense deleted...]

>
>Are you talking C or Ada here?  I'll assume Ada, as Unix/C doesn't allow light
weight
>tasking as standard, as I understand it.
>

Just because tasking is part of the Ada language spec doesn't make it
any more sacred. (BTW, I use Ada tasking and like it :-)  You are
sending the wrong message in your response that it's ok to use tasks
and not think about the design of the software because -- "Hey!  It's
Ada.  It'll take care of everything for me!"  -- wrong answer, as I'll
point out below...


>
>what *standard* way of doing it in C?  As I see it, Unix offers no standard
>re-entrancy at all.  It does offer forks, which are child processes, running i
n a copy
>of their parents' environments - that's not re-entrancy.  VMS (for example) do
es offer
>true re-entrancy, which no doubt is supported from within C.
>

This is not a correct set of statements.

Note the "quoted" use of the term *standard*.  There are several 
implementations of light-weight threads in Unix (eg. what is Mach 
for an example).

In what VMS manual does DEC claim "true re-entrancy" ?  One can write 
non-reentrant software just as easy in VMS as in Unix or any other 
system which will allow one thread of control to interrupt another 
thread of control within the same address space.


>
>Ada re-entrancy (read - tasking) is standard across operating systems.  (Of co
urse, the
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            NOT TRUE !!!


I believe this confirms the fact that you are not understanding the
term "re-entrant".


I'll try to explain one last time:

Here's a more direct example:

consider the following *package* (just typed it in, won't compile as is)
it's ugly, but I hope it gets the point across:

--------------------------------------------------------------------

package body Non_Reentrant_Code is


  --
  --  First some unprotected package state data for us to muck with
  --
  the_values : array ( 1..some_very_huge_integer ) of Float ;
  the_index  : integer ;


  --
  --  then a procedure to muck with it
  --
  procedure Load_The_Values is

  begin

    for the_index in the_values'RANGE loop

      the_values(the_index) := some_random_value ;

    end loop;

  end Load_The_Values ;


end Non_Reentrant_Code ;


-------------------------------------------------------------------------------
-


Ok, now go out and create many tasks and have them start calling the
procedure:

  Load_The_Values

What happens when task X starts filling up the array and changing the
value of "the_index", then gets interrupted by task Y to who start's
filling up the array and *ALSO* changing the value of the "the_index"?
The procedure Load_The_Values is known as non-reentrant.

See the problem now ?

Hence, an example of reentrant code is code which *CAN* be executed
from more than one thread of control at a time.  The above design is
not multi-threaded safe and the Ada code is *NOT* reentrant regardless
of operating system.  (assuming interruptable tasks are implemented by
the Ada RTS).


>
>what *standard* way of doing it in C?  As I see it, Unix offers no standard
>re-entrancy at all.  It does offer forks, which are child processes, running i
n a copy
>of their parents' environments - that's not re-entrancy.  VMS (for example) do
es offer
>true re-entrancy, which no doubt is supported from within C.
>

Not true.  Re-entrant code is a design issue, not a language or
operating system issue.


Was that nicer ?  I really tried hard not sound as if I was flaming,
however, if you're gonna put statements out in public, you gotta
be able to take the heat when they're wrong...in particular, I don't
care to be reversed-flamed with mis-information :-)

If the oven's too hot, don't stand in the kitchen.

I suggest a followup to /dev/null, unless the flame content is worth
net band-width.





John Goodsen

with Standard_Disclaimer; Use Standard_Disclaimer;

widget!jgg@uunet.uu.net
^^^^^^^^^^^^^^^^^^^^^^^
Feel better ?


-- 

             reply	other threads:[~1992-04-13 21:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-04-13 21:54 Xmiester [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-04-04 19:20 Ada / X / Motif multi-tasking issues John Goodsen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox