multitasking Forth

Chris Hinsley

unread,

Oct 28, 2012, 9:50:09 AM10/28/12

to

In a multitasking or multithreading Forth, does each thread have it's
own dictionary ? Does the dictionary 'fork' at the point a new task is
created ?

How is accsess to the dictionary mediated ? Can only the root thread
create new words ?

How does FORGET and MARKER get handled if not ?

Chris

Andrew Haley

unread,

Oct 28, 2012, 1:09:50 PM10/28/12

to

Chris Hinsley <chris....@gmail.com> wrote:
> In a multitasking or multithreading Forth, does each thread have it's
> own dictionary ?

They can. In Forth, Inc. terminology these are called TERMINAL and
BACKGROUND tsaks.

> Does the dictionary 'fork' at the point a new task is created ?

In a TERMINAL task, yes.

> How is accsess to the dictionary mediated ? Can only the root thread
> create new words ?

No, each TERMINAL task has its own dictionary, PAD, etc.

Andrew.

Elizabeth D. Rather

unread,

Oct 28, 2012, 1:59:50 PM10/28/12

to

The model that FORTH, Inc. used for many years in polyFORTH and its
predecessors featured a shared main dictionary with private dictionaries
for certain tasks defined as "terminal" tasks. In the days of
minicomputers (e.g. PDP-11) there could be many actual users, each with
a "dumb" terminal. We had systems with 32 or more such users on a
central CPU.

The original task was named OPERATOR, and it alone had the capability to
add definitions to the root dictionary (in addition to having a private
dictionary). Other terminal tasks' private dictionaries linked to that
root dictionary, which contained general Forth words as well as shared
portions of the application. Each task had "user variables" that
controlled private dictionary allocation, search order, etc. FORGET
could work only in the user's private dictionary space (this was
pre-MARKER). EMPTY cleared the user dictionary, leaving the task
connected to the top of the root dictionary.

Other tasks, called "background" tasks, had fewer user variables no
provision for private definitions. They executed code in the shared
thread, but had private user variables for stack pointers, etc.

Nowadays, we see a lot less need for private dictionaries, and
SwiftForth does not support them. However, it still supports terminal
tasks with independent I/O and user interface parameters.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Stephen Pelc

unread,

Oct 29, 2012, 9:49:29 AM10/29/12

to

On Sun, 28 Oct 2012 07:59:50 -1000, "Elizabeth D. Rather"
<era...@forth.com> wrote:

>On 10/28/12 3:50 AM, Chris Hinsley wrote:
>> In a multitasking or multithreading Forth, does each thread have it's
>> own dictionary ? Does the dictionary 'fork' at the point a new task is
>> created ?

Back in the dim and distant, when "computers" were expensive, having
multiple users with compilation rights on one Forth system was common.
When "personal" computers became common, most Forth systems assumed a
single user but multiple threads. This has been the dominant model in
embedded systems for a long time.

The only application when we really have to consider dictionary access
is when handling web servers that use the on-board Forth for
server-side scripting.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads