process.txt

汇编编程艺术

Description:

Fork spawns a new process.  You make a single call to fork but it returns
twice- once for the parent process (the original caller to fork) and once
for the child process (the new process created by fork).  On entry to fork
ES:DI must point at a PCB for the new process which has the REGSP and
REGSS fields initialized to point at the last word in a stack set aside for
the child process.  *THIS IS VERY IMPORTANT!*

On return, the code following the call to FORK can test to see whether the
parent is returning or the child is returning by looking at the value in
the AX register.  AX will contain zero upon return to the parent process.
It will contain a non-zero value, which is the process ID, when returning
to the child process.  When the parent process returns, FORK returns the
process ID of the child process in the BX register.  The parent process can
use this value to kill the child process, should that become necessary later
on.  If the child needs access to the parent's process ID, the parent process
should store away its process ID in a variable before calling the FORK
routine.  Note that with the exception of the AX, BX, SP, and SS registers,
FORK preserves all register values and returns the same set of values to both
the parent and child processes.  In particular, it preserves the value of
the DS register so the child will have access to any global variables in
use by the parent process.

FORK does *not* copy the parent's stack data to the child's stack.  Upon
return from FORK, the child's stack is empty.  If you call FORK after
pushing something on the stack (e.g., a return address because you've called
FORK inside some other procedure), that information will not be placed on the
stack of the child process.  If you such information pushed on the child's
stack, you will need to save SS:SP prior to calling FORK (in a global
variable) and then push the data pointed at by this saved value onto the
child's stack upon return.  Of course, it's a whole lot easier if you simply
don't count on anything being on the child's stack when you get back from
FORK.  In particular, don't call FORK from inside some nested routine and
expect the child process to return to the caller of the routine containing
FORK.

Include:	stdlib.a or process.a

Routine: die
------------

Category:             Processes

Registers on entry:   None

Registers on return:  None

Flags affected:       None

Example of Usage:

			die

Description:

Die kills the current process.  Control is transferred to some other process
in the process manager's ready-to-run queue.  Control never returns back to
the current process.

Note: if the current process is the only process running, calling DIE may
crash the system.

Include:	stdlib.a or process.a

Routine: kill
-------------

Category:             	Processes

Registers on entry:   	AX-	Process ID of process to terminate.

Registers on return:  	None

Flags affected:       	None

Example of Usage:

			mov	ax, ProcessID
			kill

Description:

KILL lets one process terminate another.  Typically, a parent might kill a
child process, although any process which knows the process ID of some other
process can kill that other process.

If a process passes its own ID to KILL, the system behaves exactly as though
the process called the DIE routine.

If a process passes its own ID to KILL and it is the only process in the
system, the system may crash.

Include:	stdlib.a or process.a

Routine: yield
--------------

Category:             	Processes

Registers on entry:   	None

Registers on return:  	None

Flags affected:       	None

Example of Usage:

			yield

Description:

YIELD voluntarily gives up the CPU.  The remainder of the current time slice
is given to some other process and the current process goes to the end of the
process manager's ready to run queue.  This call is particularly useful for
passing control between two cooperating process where one process needs to
wait for some action to complete and you don't feel like using semaphores
to synchronize the two activies.  This call is roughly equivalent to
"COCALL <next available process>".

Include:	stdlib.a or process.a

Routine: coinit
---------------

Category:             	Processes

Registers on entry:   	ES:DI-	Points at an empty PCB for the current process.

Registers on return:  	None

Flags affected:       	None

Example of Usage:

MainProcess		pcb	{}
			 .
			 .
			 .
			lesi	MainProcess
			coinit


Description:

COINIT initializes the coroutine package and sets up an internal pointer
to the PCB specified by ES:DI (the "current coroutine" pcb).  On the next
COCALL, the process state will be saved in the pcb you've specified on the
COINIT call.  Note that you do not have to initialize this pcb in any way,
that will all be taken care of by COINIT and the COCALL.

Include:	stdlib.a or process.a

Routine: cocall/cocalll
-----------------------

Category:             	Processes

Registers on entry:   	ES:DI-	Points at a PCB for the new coroutine
				(COCALL only).
			CS:IP-	Points at a pointer to a PCB for the new
				coroutine (COCALLL only).

Registers on return:  	None

Flags affected:       	None

Example of Usage:

OtherProcess		pcb	{----}
YetAnotherProcess	pcb	{----}
			 .
			 .
			 .
			lesi	OtherProcess
			cocall
			 .
			 .
			 .
			cocall	YetAnotherProcess

Description:

COCALL switches context between two coroutines.  There are two versions of
this call, although you use COCALL to invoke both of them: COCALL and COCALLL.
For COCALL, you must pass the address of a PCB in ES:DI.  When calling COCALL
in this fashion, the operand field of the COCALL instruction must be blank
(see the example above).  COCALLL expects the address of the pcb to follow
in the code stream.  The COCALL macro looks for an operand and, if one is
present, it automatically creates the appropriate call to COCALLL and inserts
the address of the PCB in the code stream (again, see the example above).

Before you start a coroutine for the first time by calling COCALL, you must
properly initialize the pcb for that coroutine.  You must provide initial
values for the regsp, regss, regip, and regcs fields of the pcb (fields two
through five in the pcb structure).  Regsp and regss must point at the last
word of an appropriately sized stack for that coroutine; regip and regcs
must point at the initial entry point for the coroutine.  For example, if you
want to switch between the current process and a coroutine named "CORTN", you
could use the following code:

MainCoRtn	pcb	{}
CoRtnPCB	pcb	{0,offset CoRtnStk, seg CoRtnStk,
						offset CoRtn, seg CoRtn}
		 .
		 .
		 .
		lesi	MainCoRtn
		coinit
		 .
		 .
		 .
		cocall	CoRtnPCB
		 .
		 .
		 .
CoRtn		proc
		 .
		 .
		 .
		cocall	MainCoRtn
		 .
		 .
		 .
CoRtn		endp
		 .
		 .
		 .
		db	1024 dup (?)
CoRtnStk	dw	0


Include:	stdlib.a or process.a

Routine: waitsemaph
-------------------

Category:             	Processes

Registers on entry:   	ES:DI-	Points at a semaphore variable

Registers on return:  	None

Flags affected:       	None

Example of Usage:

DOSsemaph		semaphore	{}
			 .
			 .
			 .
			lesi	DOSsemaph
			WaitSemaPh
			 .
			 . <This is the critical section>
			 .
			lesi	DOSsemaph
			RlsSemaPh

Description:

WaitSemaPh and RlsSemaPh protect critical regions in a multitasking
environment. WaitSemaPh expects you to pass the address of a semaphore
variable in ES:DI.  If that particular semaphore is not currently in use,
WaitSemaPh marks the semaphore "in use" and immediately returns.  If the
semaphore is already in use, the WaitSemaPh queues up the current process
on a waiting queue and lets some other process start running.  Once a process
is done with the resource protected by a semaphore, it must call RlsSemaPh
to release the semaphore back to the system.  If any processes are waiting
on that semaphore, the call to RlsSemaPh will activate the first such process.
Note that a process must not make two successive calls to WaitSemaPh on a
particular semaphore variable without calling RlsSemaPh between the calls.
Doing so will cause a deadlock.

Include:	stdlib.a or process.a

Routine: rlssemaph
------------------

Category:             	Processes

Registers on entry:   	ES:DI-	Points at a semaphore variable

Registers on return:  	None

Flags affected:       	None

Example of Usage:	See WaitSemaPh

Description:

RlsSemaPh releases a semaphore (also known as "signalling") that the current
process has aquired via a call to WaitSemaPh.  Please see the WaitSemaPh
explaination for more details.  You should not call RlsSemaPh without first
calling WaitSemaPh.  Doing so may cause some inconsistencies in the system.

Include:	stdlib.a or process.a