Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!decvax!tektronix!tekcrl!tekgvs!toma
From: toma@tekgvs.TEK.COM (Tom Almy)
Newsgroups: comp.lang.forth
Subject: Re: Multi-user Forth
Message-ID: <2573@tekgvs.TEK.COM>
Date: Tue, 18-Aug-87 10:41:42 EDT
Article-I.D.: tekgvs.2573
Posted: Tue Aug 18 10:41:42 1987
Date-Received: Fri, 21-Aug-87 06:41:49 EDT
References: <9.2122EF36@circle.UUCP>
Reply-To: toma@tekgvs.UUCP (Tom Almy)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 71

In article <9.2122EF36@circle.UUCP> rat@circle.UUCP (David Douthitt) writes:
>I would think that task-switching during NEXT would create too high of an 
>overhead. Seems to me that switching during : or ; would be more 
>reasonable.  However, I would still prefer PAUSE and similar for more 
>control.

The scheme used in the Multi User Forth that I posted last week changes on
"PAUSE". (This is F83)

> 
>However, I would like to be able to have a multitasking Forth which can 
>handle having more than one file open at a time; this is with a 
>single-user operating system (namely Prodos, but MS-DOS or CP/M are also 
>single-user similarly). How in tarnation would you keep track of the open 
>files?

Each task has a file number as one of its user variables.  So each user can 
do a "1 LIST" simultaneously and yet each may be displaying a different 
screen!  The block buffers' headers have both the block number and file number
and the LRU assignment algorith works over all users-- the buffer pool is
shared rather than assigned.  For smoothest operation there should be at 
least as many buffers as users, but it is not required (ever see disk 
thrashing?).

> 
>The big problem is that I want two users to be able to write in the same 
>file at the same time; so I need record-locking but dont know how to 
>implement it. Any thoughts?

Yes, use semaphores on the block buffers, and add a new word, RELEASE,
to signify release of the block buffer.  Change the block allocation
algorithm to skip locked block buffers.  Of course, if the task can get
all of its work done without doing anything that causes a PAUSE, then
you are home free without going to this trouble.  

USER VARIABLE curblk

: LOCKINGBLOCK  DUP curblk !  
	BLOCK ( the old code )
	DUP { offset to header semaphore location } SEMA ;

: RELEASE  curblk @ BLOCK { offset to header semaphore location } PHORE ;

Where SEMA and PHORE are implemented as:

: SEMA ( locationToLock -- )
	BEGIN DUP @ WHILE PAUSE REPEAT  
	ON ;

: PHORE ( locationToRelease -- )
	OFF ;


 
>By the way, I would say that there are SOME of us STILL using CP/M out 
>here... too bad the F83 isnt Z80 code though. Better yet, somebody otta 
>write a decent F83 for ZCPR3.

I recently stopped using a Z80, but the F83 code can be Z80ized.
The inner interpreter address should be put in IX (or IY) and JMP [IX]
used to get to it.  The multiply and divide primitives can be rewritten
to get MUCH better performance, and of course CMOVE can be improved.  The
improvement in speed won't be anything to write home about, though.  The
best bet for speed improvement is to change the implementation to direct
threaded code.

Tom Almy
Tektronix, Inc.
toma@tekgvs.TEK.COM

(Standard disclaimer applies)