ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/27/90)
Category 3, Topic 14 Message 12 Sun Aug 26, 1990 R.BERKEY [Robert] at 14:51 PDT From: GEnie R.BERKEY (Robert) Subject: Re: Experimental Ideas In <GEnie Category 3, Topic 5, Message 36, Mon Jul 30, 1990, at 00:48 CDT>, F.SERGEANT [Frank] writes: > I've thought one of CM's ideas on multi-tasking was that > instead of having a single task requiring complicated > co-ordination, you have a number of simple tasks, each of which > can be tested alone. So, in (this) theory, multi-tasking should > make the debugging easier, but it sounds like you have experience > to the contrary. Oh, I wouldn't disagree with CM's analysis. One of my problems was that I had no experience in developing personal tools for working with the various tasks. Maybe I could have factored it better to make it easier to test, who knows. The issue remains that when another task has no terminal i/o, the normal display tools must be modified, access is different to the user variables, and this complicates debugging. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/06/91)
Date: 04-02-91 (08:30) Number: 1724 of 1724 (Echo)
To: GARY SMITH Refer#: 1701
From: JACK WOEHR Read: NO
Subj: MULTI-TASKING AND MULTI-U Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> From: kube@cs.UAlberta.CA (Ron Kube) Subject: Multi-tasking in FORTH
-> Summary: Question about multi-tasking in FORTH Keywords: multi
-> tasking Message-ID: <kube.670357191@menaik> Date: 30 Mar 91 18:19:51
-> GMT Sender: news@cs.UAlberta.CA (News Administrator) Distribution:
-> comp.lang.forth Organization: University of Alberta, Edmonton, Canada
->
-> MY QUESTION: Are there other SBCs(ie New Micros Inc)that are
-> multi-tasking? ----------- Is the word TASK part of fig-FORTH
-> standards (I suspect not)?
Many, if not most control-oriented Forth systems are multitasking,
as is our Vesta Forth-83+, Forth-83A+ and Forth-83i96 on our range
of single board computers (80x88,68000,80196).
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/26/91)
Date: 04-23-91 (13:00) Number: 1967 of 1988 (Echo) To: ALL Refer#: NONE From: DOUGLAS ADDISON Read: HAS REPLIES Subj: MULTITASKING Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Greetings: In Leo Brodie's Starting Forth, the author describes a "multiprogrammer" and shows a memory map for the same. The one listed showed several different user areas, some supporting terminal processes. LMI's documentation does not explicitly show other terminal processes in its PCF multitasker memory map, although it appears that such could be crafted. Has anyone ever done this with PC/UR Forth? Is it implicitly supported? How would someone do such a thing? Would it be possible to have another terminal hooked up to a serial port and thus have a multi-user interface on one machine running PC Forth? I'd be interested in any informed feedback on this, Thanks. Doug Addison NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/26/91)
Date: 04-23-91 (13:36) Number: 1968 of 1988 (Echo) To: DOUGLAS ADDISON Refer#: NONE From: RAY DUNCAN Read: 04-23-91 (14:12) Subj: MULTITASKING Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Leo Brody's experience was with polyFORTH by FORTH Inc. All their systems are multiuser multitasking (or at least are capable of it). Our systems are single-user multitasking; we assume that there is only one keyboard and screen. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/12/91)
Category 3, Topic 14 Message 19 Mon Jun 10, 1991 ELLIOTT.C at 08:20 EDT JAX, I just saw your Dr. Dobbs article. What about queuing instead of roundrobin in the context of something like your "medium- heavyweight" multitasker? ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/14/91)
Date: 06-11-91 (08:23) Number: 137 of 138 (Echo)
To: ELLIOTT.C Refer#: 129
From: JACK WOEHR Read: NO
Subj: MULTI-TASKING AND MULTI-U Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> JAX, I just saw your Dr. Dobbs article. What about queuing instead
-> of roundrobin in the context of something like your "medium-
-> heavyweight" multitasker?
That's an interesting idea ... do you have an example in mind?
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/16/91)
Date: 06-13-91 (22:42) Number: 150 of 162 To: JACK WOEHR Refer#: 137 From: ELLIOTT CHAPIN Read: NO Subj: MULTI-TASKING AND MULTI-U Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) -> JAX, I just saw your Dr. Dobbs article. What about queuing instead -> of roundrobin in the context of something like your "medium- -> heavyweight" multitasker? JW> That's an interesting idea ... do you have an example in mind? Nothing specific; but I suppose it came to me in part because of Brad Rodriguez' article "Multiprocessor Forth Kernel" in Forth Dimensions vol. XI, #3. Elliott Chapin --- ~ DeLuxe} 1.12 #4315 ~ PCRelay:CRS -> #460 RelayNet (tm) 4.10 Canada Remote Systems * Toronto, Ontario <<<>>> ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/16/91)
Date: 06-14-91 (21:41) Number: 162 of 162 (Echo)
To: ELLIOTT CHAPIN Refer#: 150
From: JACK WOEHR Read: NO
Subj: MULTI-TASKING AND MULTI-U Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> Nothing specific; but I suppose it came to me in part because of Brad
-> Rodriguez' article "Multiprocessor Forth Kernel" in
-> Forth Dimensions vol. XI, #3.
Anyway, for a small number of tasks, a prioritized round robin
is just as effective as a prioritized queue. It's when you have a large
number of tasks, as in a multiuser system (UNIX) or in a process control
system (EMCS/Express from FInc) wherein you have to assure that certain
critical tasks execute ahead of others, and complete their work before a
lower priority task gets its first whack at processing, that queueing
becomes important.
There is no reason Forth couldn't task in any of these other
ways, it's just tradition and the influence of the low overhead and
deterministic behaviour of round-robin tasking that has influenced the
Forth taskers you find in most systems.
As to Determinism ... a recent program I wrote was so
deterministic in its task ( four tasks) overhead that I was able to
write music for one task that plays in rythm without any special tricks,
just the very predictable time slice that the traditional round robin
gives to it.
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/25/91)
Category 3, Topic 14
Message 24 Mon Jun 24, 1991
D.RUFFER [Dennis] at 00:22 EDT
I participated in the Real Time working group at the Rochester Forth
Conference this last week, and the subject of multi-tasking schedulers came
up. The basic schemes discussed were round-robin and pre-emptive schedulers.
The conclusion was that both have their advantages and disadvantages.
The pre-emptive schemes have more general overhead when switching tasks, and
the timing of events (when multiple tasks are active) can be difficult. The
biggest advantages are that the time from interrupt to task activation is very
short and predictable and the task switch overhead can be reduced by
minimizing the number of times you switch.
The multi-tasker has the lower task switch overhead, but it is always
switching tasks so the more tasks you have the more total overhead you have to
deal with. You can determine when you will let other tasks have control, but
you do not know how long you will be gone when you do the PAUSE. Also, the
time from interrupt to task activation is not predictable, since you must wait
until the current task releases the CPU.
Each has its tradeoffs, but the round-robin is certainly easier to implement
than the pre-emptive schemes. Obviously, we did not resolve the debate
between the techniques, but we did learn more about how the other works.
{B-{)> DaR
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp