comp.lang.ada
 help / color / mirror / Atom feed
From: sdcc6!sdcc5!cs171wag@ucsd.edu  (Bob Kitzberger)
Subject: Re: Ada Tasking problem
Date: 25 Nov 91 00:04:26 GMT	[thread overview]
Message-ID: <25883@sdcc6.ucsd.edu> (raw)

mfeldman@milton.u.washington.edu (Michael Feldman) writes:

>Once your main program called the task's entry, causing the
>task to get control, it simply kept it, finished its loop,
>then gave the CPU back to MAIN. The standard Ada recommendation
>to prevent this from happening is to put a brief DELAY in each loop
>iteration, forcing (in your case) MAIN and the task to ping-pong 
>control. You need to add, say, DELAY 0.1 just before both END LOOP
>statements.
>>
>This is a portable solution: it forces the processor
>to be shared even in the absence of time-slicing.

Many Ada runtimes will 'special case' a delay of 0.0, resulting in an
immediate context switch to another task of equal priority (i.e. round-robin
to the next available task in the same priority slot in the ready queue.)
Of course, this is not very portable, but it doesn't have the overhead of
delay queue insertion and expiry.  Your tradeoff mileage may vary ;-)

	.Bob.

             reply	other threads:[~1991-11-25  0:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-11-25  0:04 Bob Kitzberger [this message]
  -- strict thread matches above, loose matches on Subject: below --
1991-11-26  9:10 Ada Tasking problem paul goffin
1991-11-25 17:02 agate!spool.mu.edu!wupost!zaphod.mps.ohio-state.edu!ub!dsinc!gvlf3.gvl.un
1991-11-25  4:04 cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!ogicse!milton
1991-11-23  0:03 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!usen
1991-11-21 13:04 Eric E. Mays 52202
replies disabled

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