From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 13 Apr 92 21:54:34 GMT From: widget!jgg@uunet.uu.net (Xmiester) Subject: Re: Ada / X / Motif multi-tasking issues Message-ID: <1992Apr13.215434.8973@widget!uunet.uu.net> List-Id: 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 ? --