VADSWorks time-slicing question

VADSWorks time-slicing question

[Jeff Melvaine]

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" <levine%segur.ICS.UCI.EDU@metro.ucc.su.OZ.AU>
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
>