LOMAX@bio-medical-physics.aberdeen.ac.uk (01/27/89)
Can anybody out there enlighten me as to how a single processor handles
multiple processes waiting for communications. Do these waiting processes use
any CPU time, and do they differ depending on whether they are waiting on hard
or soft channels.
Tony Lomax....
P.S.
The reason for asking is that I wish to make absolute measurements of CPU time
for a particular process and I therefore need to know if waiting processes will
add to the measured CPU time. w-colinp@microsoft.UUCP (Colin Plumb) (01/28/89)
LOMAX@bio-medical-physics.aberdeen.ac.uk wrote: > Can anybody out there enlighten me as to how a single processor handles > multiple processes waiting for communications. Do these waiting processes use > any CPU time, and do they differ depending on whether they are waiting on hard > or soft channels. A process waiting for communication uses only memory, not CPU cycles. Of course, copying the message (whether it's by a soft channel or DMA from a link) does take memory cycles, and the latter can occur even if the process isn't running. Things that can take CPU resources away from a running process: - The timer waking up a process - A link communicating or finishing and waking up a process - The event channel waking up a process - Time-slicing at the low priority level - For completeness, the reset pin has the obvious effects Everything else is in response to some explicit action by the currently running process. I've had demos with 16000 processes runnning around. If they were all sleeping, I could have a quarter of a million. -- -Colin (uunet!microsof!w-colinp)
ian@uowcsa.cs.uow.oz (Ian Gorton) (05/17/89)
Just a quick question..... Consider a scenario where there are many processes instantiated on a transputer, but only one low priority process is able to execute, and this situation lasts for quite a long time (perhaps a second or 2). I assume this process, the only executable process, will be treated as all low priority process are normally treated, and be timesliced at regular intervals. Though as it is the only process able to run, I also assume it will be immediately become active again. The question is...(if my assumptions are correct?!), what is the time interval between the process being de-activated and it becoming active again. Not very much, I (again) assume. Anyone know the answer (Inmos yet again assume) Yours assumptiously..... Ian
peter@wacsvax.OZ (Peter Dodd) (05/20/89)
Ian, Given a low priority process executing alone : > The question is...(if my assumptions are correct?!), what is the time > interval between the process being de-activated and it becoming active > again. Not very much, I (again) assume. Im not sure, but it will be one of two cases : 1) The processor deschedules the process then reschedules the process who's workspace is pointed to by the FPtr1 register, which will take less than 1us. ( Normal context switch time ) 2) The processor will recognise that the FPtr1 and current Workspace registers are identical, and continue execution without descheduling. Even less time than context switching. Peter. ---------------- peter@wacsvax.oz
peter@wacsvax.OZ (Peter Dodd) (05/20/89)
Sorry for the repost... > Given a low priority process executing alone : > >> The question is...(if my assumptions are correct?!), what is the time >> interval between the process being de-activated and it becoming active >> again. Not very much, I (again) assume. > > Im not sure, but it will be one of two cases : Of course it will be neither, since both FPtr1, and BPtr1 will be NULL. As they point to workspaces that are active awaiting execution, excluding the currently executing process. Hence descheduling cannot occur. Peter. ---------------- peter@wacsvax.oz
malc@inmos.co.uk (Malcolm Boffey) (05/31/89)
When a process timeslices, it is put onto the back of the relevant
(low priority) queue, even if the queue was empty. The first process (which may
of course be the same as what was just running) is then taken off the queue and
scheduled. If the empty queue was treated as a special case, it would save
about 0.1%, while costing more microcode and hence space.
\input {stddisclaimer.tex}
--
Malcolm Boffey, Transputer Group, Inmos. | Inmos Ltd,
email: malc@inmos.co.uk | 1000 Aztec West, Almondsbury,
JANET: MALC@UK.CO.INMOS | Brisol BS12 4SQ.
UUCP: ...uunet!mcvax!ukc!inmos!malc | Tel. +44 454 616616 x530