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: 24 Mar 92 03:44:56 GMT From: sun-barr!west.West.Sun.COM!sunaus!assip.csasyd!condor!jeffm@ames.arc.nasa .gov (Jeff Melvaine) Subject: VADSWorks time-slicing question Message-ID: List-Id: Thank you to all who responded to my question. We appreciate the variety of insights and perspectives gained from the answers, and our quandary has been resolved. > This question is addressed to those familiar with the Sun VADSWorks system fo r > Sun-4 and/or 680x0 targets. Our system designers wish the code to run with > time slicing disabled for reasons of efficiency. (We are aware of the > consequences of blocking a lightweight task in this mode of operation). The > discussion point is that there are two ways of disabling time slicing: > statically (by modifying the VADS kernel configuration table entry), and > dynamically (by calling a subprogram in package vx_tasking). The latter appe ars > to require less work to set up. Is there any reason to prefer the static > method? > From: "David L. Levine" It doesn't require the addition to the code that would impair portability. I use the static approach to avoid implementation dependencies in my code. On the other hand, if you know that the code will always be used in a VADS environment, turning time slicing off in the code is much more visible than the modified ada.lib. David L. Levine Internet: levine@ics.uci.edu UUCP: uunet!ucivax!levine BITNET: levine@uci > I would expect that the effect of calling vx_tasking.set_time_slicing_enabled > was to enable/disable delivery of a periodic SIGALRM to trigger rescheduling, > and that choice between the two methods is largely a matter of style. I woul d > appreciate input from anyone who can shed more light on this. > From: esther%verdix.com@metro.ucc.su.OZ.AU (Esther Lumsdon) Several of the vx_tasking calls "queue" actions that will take effect the next time the kernel code is run. This is not intuitive. Sorry about that. set_time_slicing_enabled is one of those. (I think that all of the time slice manipulation calls are.) To make the set_time_slicing_enabled take effect, follow it by a delay (0.0) statement. This will enter the kernel, and your change will take effect. Generally, customers find that they need to alter the default task stack size, or change the memory allocation method, so they statically set time slicing since they have to build a usr_conf library anyway. And they avoid that delay (0.0) statement. ------ Esther Lumsdon Product Support Engineer, Verdix Corporation 205 Van Buren St Herndon, Virginia, USA esther@verdix.com or esther%verdix.com@uunet.uu.net From: bobf%verdix.com@metro.ucc.su.OZ.AU Jeff, after reading your post, I uncovered a slight deficiency in our usr_conf implementation. There are actually *three* ways to enable time-slicing in a VADSworks application. One of these ways unfortunately does not work. (1) In file v_usr_conf_b.a in library usr_conf, configuration section #c2d provided the time-slicing defaults: -- #c2d: TIME SLICE CONFIGURATION PARAMETERS: TIME_SLICING_ENABLED => TRUE, TIME_SLICE_INTERVAL => 1.0, As you can see, time-slicing should be enabled by default, yet it is not. There is a slight problem in that at program startup, TIME_SLICING_ENABLED is incorrectly evaluated. As a result, modifying v_usr_conf to enable time-slicing will not work. However, there are two other methods: (2) The VADSexec call V_XTASKING.set_time_slicing_enabled can be used to turn time-slicing on and off. The slice interval is the one in v_usr_conf (this *does* work). This call turns time slicing on for Ada tasks. (3) The VxWorks kernelLib call kernelTimeSlice() turns time-slicing on for all tasks, not just Ada tasks. This call may be invoked from the VxWorks shell, or called from an Ada or C routine. The choice between these three methods is more than stylistic. Modifying v_usr_conf implements changes applied to *all* Ada applications linked with the user configuration. The latter two methods are used on an individual application basis. To summarize, modifying v_usr_conf implements GLOBAL changes, while calling VADSexec/VxWorks routines implement LOCAL changes. Bob Foery Verdix Product Support Engineer bobf@verdix.com From: vestal%src.honeywell.com@metro.ucc.su.OZ.AU (Steve Vestal) Well, I used a beta release of VADSWorks for a Mizar board a couple of years ago. I used the dynamic call to disable time slicing, but in the course of some very detailed benchmarking studies discovered that the runtime system still received and processed a signal at 1 second intervals. My speculation is that the disabling was done inside the runtime SIGALRM handler, rather than by just disabling SIGALRMs. These may possibly be needed for something else (e.g. resuming suspended tasks from the delay queue), and it may not depend on whether disabling is done statically or dynamically. So, no matter what you do, you may get periodic SIGALRMS, but time slicing will be disabled and "unnecessary" context swaps will be eliminated. > Jeff >