Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #50575 > unrolled thread

POSIX vs Forth cooperative tasker

Back to article view | Back to comp.lang.forth

Contents

  POSIX vs Forth cooperative tasker foxaudioresearch@gmail.com - 2016-08-31 07:11 -0700
    Re: POSIX vs Forth cooperative tasker Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-31 11:02 -0500
    Re: POSIX vs Forth cooperative tasker albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-31 20:40 +0200
      Re: POSIX vs Forth cooperative tasker foxaudioresearch@gmail.com - 2016-08-31 11:54 -0700
    Re: POSIX vs Forth cooperative tasker Gary Bergstrom <forthprgrmr@gmail.com> - 2016-08-31 11:34 -0700
    Re: POSIX vs Forth cooperative tasker Paul Rubin <no.email@nospam.invalid> - 2016-08-31 17:06 -0700
      Re: POSIX vs Forth cooperative tasker josv@planet.nl - 2016-09-01 01:00 -0700
        Re: POSIX vs Forth cooperative tasker albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-01 10:42 +0200
          Re: POSIX vs Forth cooperative tasker albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-01 11:13 +0200
            Re: POSIX vs Forth cooperative tasker foxaudioresearch@gmail.com - 2016-09-01 09:37 -0700
              Re: POSIX vs Forth cooperative tasker Julian Fondren <julian.fondren@gmail.com> - 2016-09-01 20:44 -0700
                Re: POSIX vs Forth cooperative tasker albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-02 11:39 +0200
            Re: POSIX vs Forth cooperative tasker franck.bensusan@gmail.com - 2016-09-01 15:06 -0700
          Re: POSIX vs Forth cooperative tasker josv@planet.nl - 2016-09-01 03:11 -0700
      Re: POSIX vs Forth cooperative tasker foxaudioresearch@gmail.com - 2016-09-01 08:26 -0700

#50575 — POSIX vs Forth cooperative tasker

There is discussion in another thread about POSIX so I thought I should 
migrate to a new topic.

With POSIX being so large and UNIX oriented, would it be better to
get our house in order on word names for the Forth cooperative tasker which
has been in use in various forms for 4 decades.  It is one of the coolest
things about forth on small systems. It makes multi-tasking simple
with no OS.

Here are the words I use. (with most of the code removed)

PID is process I.D.  which typically is an address, but could be something else.

: MYSELF         ( -- PID )     UP @ ;
: LOCAL          (  PID addr -- addr') myself  -  + ;
: TASK:          (  stack-size -- )   \ ie, 400 TASK: DO-SOMETHING
: SET-TASK       (  xt PID -- )       

: RESET-TASK     ( PID -- ) ... 
: INIT-MULTI     ( -- ) ...   \ init the multi-tasker
: SINGLE         ( -- )...    \ disable multi-tasking
: MULTI          (  -- ) ...  \ enable multi-tasking
: WAKE           ( PID -- )  TASK-FLAG LOCAL ON    ;  
: SLEEP          ( PID -- )  TASK-FLAG LOCAL OFF   ;
: RESTART        ( PID -- )  DUP RESET-TASK  WAKE  ;
: ?PID           ( PID -- )  \ abort if not a valid PID
: NICE          ( value PID -- ) ?PID PRIORITY LOCAL ! ;
: NICE?         ( PID -- n )     ?PID PRIORITY LOCAL @ ; 
: DREAMS        ( n --)    \ ALWAYS does at least 1 <PAUSE>
: JOB:          ( <name> )    
: ;JOB

: MS            ( n -- )  \ MS is multi-tasking friendly

Here are the additional USER VARIABLEs

TASK-LINK
TASK-FLAG
PRIORITY  ( priority is integrated with PAUSE)

: PAUSE        ( -- )  PRIORITY @ DREAMS  ; 

Of course all the terminal I/O words are vectored and TIB and PAD are 
relocatable but that is not essential to define a bare bones tasker.

I would be interested to see if there is overlap in name choice and functionality and if others believe we should get some of this "standardized".
Or does nobody care now that so many Forths run on top of an OS?

BF

[toc] | [next] | [standalone]

#50579

foxaudioresearch@gmail.com wrote:

> I would be interested to see if there is overlap in name choice and
> functionality and if others believe we should get some of this
> "standardized".  Or does nobody care now that so many Forths run on
> top of an OS?

It's possible to abstract away the differences between co-operative
and pre-emptive multi-tasking. [*]  Forth, Inc have a simple wordset
which they've used since the 1970s and it works well on both
multi-core systems running on e.g. Linux and native systems with a
co-operative scheduler.  It needs to be elaborated a little for
general use, but I think something like it would be the best overall
scheme.  I think that MPE use something similar enough to be
compatible.

There's a free trial of SwiftForth for Windows, Linux and OS X at
https://www.forth.com/download/.  It comes with docs: I'm looking at
Section 7: Multitasking in the SwiftForth Development System for Linux
and Mac OS X Reference Manual.

Andrew.


[*] For example, Java can run on co-operative threads or on a
pre-emptive system.  It makes no difference to the programs.

[toc] | [prev] | [next] | [standalone]

#50581

In article <7fddacae-373d-4cd5-a857-f4ae00486388@googlegroups.com>,
 <foxaudioresearch@gmail.com> wrote:
>There is discussion in another thread about POSIX so I thought I should
>migrate to a new topic.
>
>With POSIX being so large and UNIX oriented, would it be better to
>get our house in order on word names for the Forth cooperative tasker which
>has been in use in various forms for 4 decades.  It is one of the coolest
>things about forth on small systems. It makes multi-tasking simple
>with no OS.
>
>Here are the words I use. (with most of the code removed)
>
>PID is process I.D.  which typically is an address, but could be something else.
>
>: MYSELF         ( -- PID )     UP @ ;
>: LOCAL          (  PID addr -- addr') myself  -  + ;
>: TASK:          (  stack-size -- )   \ ie, 400 TASK: DO-SOMETHING
>: SET-TASK       (  xt PID -- )
>
>: RESET-TASK     ( PID -- ) ...
>: INIT-MULTI     ( -- ) ...   \ init the multi-tasker
>: SINGLE         ( -- )...    \ disable multi-tasking
>: MULTI          (  -- ) ...  \ enable multi-tasking
>: WAKE           ( PID -- )  TASK-FLAG LOCAL ON    ;
>: SLEEP          ( PID -- )  TASK-FLAG LOCAL OFF   ;
>: RESTART        ( PID -- )  DUP RESET-TASK  WAKE  ;
>: ?PID           ( PID -- )  \ abort if not a valid PID
>: NICE          ( value PID -- ) ?PID PRIORITY LOCAL ! ;
>: NICE?         ( PID -- n )     ?PID PRIORITY LOCAL @ ;
>: DREAMS        ( n --)    \ ALWAYS does at least 1 <PAUSE>
>: JOB:          ( <name> )
>: ;JOB
>
>: MS            ( n -- )  \ MS is multi-tasking friendly
>
>Here are the additional USER VARIABLEs
>
>TASK-LINK
>TASK-FLAG
>PRIORITY  ( priority is integrated with PAUSE)
>
>: PAUSE        ( -- )  PRIORITY @ DREAMS  ;
>
>Of course all the terminal I/O words are vectored and TIB and PAD are
>relocatable but that is not essential to define a bare bones tasker.
>
>I would be interested to see if there is overlap in name choice and functionality and if others believe we should get some of this "standardized".
>Or does nobody care now that so many Forths run on top of an OS?

I don't understand why there is something like a multi-tasker.
If I want the data structure for an extra pre-emptive process with
X dictionary space:

X THREAD-PET new

Now if I have a task that must run e.g. SIEVE-THIS

' SIEVE-THIS new

Now SIEVE-THIS runs till its ready.

Of course THREAD-PET is a create-does> word.

If I need more I create another THREAD-PET.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50583

On Wednesday, August 31, 2016 at 2:32:43 PM UTC-4, Albert van der Horst wrote:
> In article <7fddacae-373d-4cd5-a857-f4ae00486388@googlegroups.com>,
>  <foxaudioresearch@gmail.com> wrote:
> >There is discussion in another thread about POSIX so I thought I should
> >migrate to a new topic.
> >
> >With POSIX being so large and UNIX oriented, would it be better to
> >get our house in order on word names for the Forth cooperative tasker which
> >has been in use in various forms for 4 decades.  It is one of the coolest
> >things about forth on small systems. It makes multi-tasking simple
> >with no OS.
> >
> >Here are the words I use. (with most of the code removed)
> >
> >PID is process I.D.  which typically is an address, but could be something else.
> >
> >: MYSELF         ( -- PID )     UP @ ;
> >: LOCAL          (  PID addr -- addr') myself  -  + ;
> >: TASK:          (  stack-size -- )   \ ie, 400 TASK: DO-SOMETHING
> >: SET-TASK       (  xt PID -- )
> >
> >: RESET-TASK     ( PID -- ) ...
> >: INIT-MULTI     ( -- ) ...   \ init the multi-tasker
> >: SINGLE         ( -- )...    \ disable multi-tasking
> >: MULTI          (  -- ) ...  \ enable multi-tasking
> >: WAKE           ( PID -- )  TASK-FLAG LOCAL ON    ;
> >: SLEEP          ( PID -- )  TASK-FLAG LOCAL OFF   ;
> >: RESTART        ( PID -- )  DUP RESET-TASK  WAKE  ;
> >: ?PID           ( PID -- )  \ abort if not a valid PID
> >: NICE          ( value PID -- ) ?PID PRIORITY LOCAL ! ;
> >: NICE?         ( PID -- n )     ?PID PRIORITY LOCAL @ ;
> >: DREAMS        ( n --)    \ ALWAYS does at least 1 <PAUSE>
> >: JOB:          ( <name> )
> >: ;JOB
> >
> >: MS            ( n -- )  \ MS is multi-tasking friendly
> >
> >Here are the additional USER VARIABLEs
> >
> >TASK-LINK
> >TASK-FLAG
> >PRIORITY  ( priority is integrated with PAUSE)
> >
> >: PAUSE        ( -- )  PRIORITY @ DREAMS  ;
> >
> >Of course all the terminal I/O words are vectored and TIB and PAD are
> >relocatable but that is not essential to define a bare bones tasker.
> >
> >I would be interested to see if there is overlap in name choice and functionality and if others believe we should get some of this "standardized".
> >Or does nobody care now that so many Forths run on top of an OS?
> 
> I don't understand why there is something like a multi-tasker.
> If I want the data structure for an extra pre-emptive process with
> X dictionary space:
> 
> X THREAD-PET new
> 
> Now if I have a task that must run e.g. SIEVE-THIS
> 
> ' SIEVE-THIS new
> 
> Now SIEVE-THIS runs till its ready.
> 
> Of course THREAD-PET is a create-does> word.
> 
> If I need more I create another THREAD-PET.
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

So what handles keeping the thing running? An OS?

BF

[toc] | [prev] | [next] | [standalone]

#50582

On Wednesday, August 31, 2016 at 10:12:01 AM UTC-4, foxaudio...@gmail.com wrote:
> There is discussion in another thread about POSIX so I thought I should 
> migrate to a new topic....
> 
> I would be interested to see if there is overlap in name choice and functionality and if others believe we should get some of this "standardized".
> Or does nobody care now that so many Forths run on top of an OS?
> 
> BF
All of my systems use a word set very much like this. 
I don't do embedded products which run on top of an OS.
But the bickering about the specifics of a word set are not something
that I'd want to be involved with.  I'm good with what I have.
I'd be happy to extract/abstract the words I use though.

Gary

[toc] | [prev] | [next] | [standalone]

#50586

foxaudioresearch@gmail.com writes:
> I would be interested to see if there is overlap in name choice and
> functionality and if others believe we should get some of this
> "standardized".

I had the impression that lots of people have been interested in
standardizing multi-tasking, but there was not enough agreement between
interested parties to agree on a specification.  

It would be nice if you could post some documentation of your word set.
I remember being impressed by how simple the eForth multi-tasker is.

I notice your word set doesn't seem to say anything about communication
between tasks, via mailboxes or whatever.

[toc] | [prev] | [next] | [standalone]

#50593

On Thursday, September 1, 2016 02:06:13 UTC+2 Paul Rubin wrote:

> foxaudiore...com writes:
> > I would be interested to see if there is overlap in name choice and
> > functionality and if others believe we should get some of this
> > "standardized".
> 
> I had the impression that lots of people have been interested in
> standardizing multi-tasking, but there was not enough agreement between
> interested parties to agree on a specification.  
> 
> It would be nice if you could post some documentation of your word set.
> I remember being impressed by how simple the eForth multi-tasker is.
> 
> I notice your word set doesn't seem to say anything about communication
> between tasks, via mailboxes or whatever.

Here is help part of the MultiTaskingClass from Win32Forth
I hope it is readable since the lines are a bit long:

MultiTaskingClass -- For clustered tasks in objects. 
Abstract: 
CPU's with multiple cores can execute a program faster than cpu's with a single core. 
This is done by breaking up a program in smaller pieces and than execute all pieces simultaneously. 
In multiTaskingClass.f this idea is supported as follows: 
Breaking up is possible at the definition level or at the program level by the 2 classes iTask and wTask. 
Then the pieces are submitted and simultaneously executed in a number of tasks. 
Tasks are coverted to jobs and clustered in an object for easy access. 

Objects defined with iTask can be used as soon as ONE definition should be executed in a parallel way and the definition uses a do...loop. 
The method Parallel:  divides, distributes and submits for execution the specified cfa over a number of jobs. 
A started job can pickup its range for the do...loop part by using the method GetRange:. 
It is possible to change the number of simultaneous jobs before they run. 

Objects defined with wTask can be used to execute concurrently one or more different definitions. 
Use the method Submit: for executing a definition in a job. 
When a new job is submitted and the maximum number of jobs has been reached the following will happen at the next job: 
1) The system will wait till all the jobs in one que of one thread are complete. 
2) Then it will allow the submitting more jobs. 


Tasks of both classes will get their parameters at the start on the stack as soon as the method ToStack: is used just before the job is submitted. 
MultiTaskingClass.f uses the preemptive multitasking system of windows. No need to use pause. 


Typical passing of parameters to a Job: 
LockJobEntry[: myTasks 10 20 30 3 ToStack: myTasks  ['] TestTask ]Submit: myTasks 
Explanation:
 LockJobEntry[: Locks the entrypoint to protect it against overwriting.
 ToStack: Passes the 3 stack items to the stack of the job.
 ]Submit: Submits the task and unlocks the entrypoint just before it returns. 

Glossary 
code cells+@  ( a1 n1 -- n ) \ 
Multiply n1 by the cell size and add the result to address a1 then fetch the value from that address. 

code cells+!  ( n a1 n1 -- ) 
Multiply n1 by the cell size and add the result to address a1 then store the value n to that address. 

: GetValueSpMainThread ( - UpMainThread ) 
Get sp0 of the main thread. Even when a secondary thread is running. 

: SetValueSpMainThread ( - ) 
Sets the sp0 value of the main thread. This is done at the start of Forth or at the start of a turnkey 

: MainThread? ( - flag ) 
Detects if a definition is running in the main thread.
MainThread? returns true when a definition runs in the main thread. 

: GetThreadIndex ( - IDindex ) 
Each thread gets an index. GetThreadIndex returns that index. GetThreadIndex in a job can be used to target a value in an array for one thread. 

: #Hardware-threads ( - #Hardware-threads ) 
 Returns the number of hardware threads found in the CPU. 

: SetPriority ( Prio - ) 
Changes the priority of the thread. 

: below       ( -- ) 
Lowers the priority of the thread in order to keep the main thread responsive to the mouse etc. 

: #do  \ Compiletime: ( <name> -- )  Runtime: ( limit start - ) 
To construct:     do  i  cfa   loop 
EG: 
: test  10 0   #do . ; 
Will be compiled as: 
: TEST  10 0    DO  I . LOOP    ; 


Parameters for 1 job entry in a jobblock: Name:  Use:  
--  -- Note: Parameters starting wih a '>' use the &JobEntry address to get to their adress.  
&JobEntry  -- The start adress of one job entry.  
>JobCFA  -- Contains the CFA to be executed by a job.  
>JobStkDepth  -- The number of stack items for a job.  
>JobStkLast  -- A stack for a job to be executed.  
>StartTic  -- A double containing the StartTic when a job was started.  
>EndTic  -- A double containing the >EndTic when a job became complete.  
>CfaDone  -- Contains the previous Cfa of a job entry.  
>StartTime  -- A structrure containing the StartTime when a job was started.  
>EndTime  -- A structrure containing the EndTime when a job became complete.  
>Schedule  -- Reserved to hold a Schedule.  
>range  -- 2 cells to hold the start- end-index for a do...loop. used by the class iTasks.  
/StkParams  -- The maximum number of parameters to pass to a job. Default is 8.  
/JobEntry  -- The size of 1 Job entry.  
MinimumSizeJobBlock  -- Minimum size of one job entry.  
#JobParms  -- Number of parameters in one job entry.  
/TimeParams  -- Partial size of job entry to be used to erase statistics.  

: .Timestamp ( &entry - ) 
Displays the time when a job was started. 

: ms@TB         ( time-buf -- ms ) 
Returns the content of a timebuffer into milli-seconds on the stack. 

: .ElapsedJob   ( start-time-buf end-time-buf -- ) 
Displays the time that has been elapsed betweeen 2 time buffers 

0x7FFFFFFF constant MaxCountSemaphore 
The maximum count of a Semaphore 

Semaphore class 
:Class Semaphore    <Super Object 
A semaphore act as a lock that allows multiple threads to wait in line for the resource to be free. The state of a semaphore is set to signaled when its count is greater than zero, and nonsignaled when its count is zero. If the current state of the semaphore is signaled, the wait function DECREASES the count by one and waits till the semphomere gets signaled. 

:M CreateSemaphore: ( lpName lMaximumCount lInitialCount lpSemaphoreAttributes --  ) 
Creates a semaphore.
Parameters:
lpSemaphoreAttributes: Pointer to security attributes can be NULL.
lInitialCount: Specifies an initial count for the semaphore object. This value must be greater than or equal to zero and less than.
lMaximumCount: Maximum count 
lpName: Pointer to a null-terminated string specifying the name of the semaphore object. Can be NULL. 

:M ReleaseSemaphore: ( lpPreviousCount lReleaseCount -- PreviousCount ) 
Increases the count of the specified semaphore. Parameters:
lReleaseCount: Specifies the amount by which the semaphore object's current count is to be INCREASED. The value must be greater than zero. If the specified amount would cause the semaphore's count to exceed the maximum count that was specified when the semaphore was created, the count is not changed and the function returns FALSE.
lpPreviousCount: Pointer to receive the previous count for the semaphore. Can be NULL if the previous count is not required 

:M Increase:  { \ lpPreviousCount -- } ( -- PreviousCount ) 
Releases the semaphore by one. 

:M DecreaseWait: ( ms -- ) 
DECREASES the count of the semaphore by one. 

: SignalObjectAndWait ( bAlertable  dwMilliseconds hObjectToWaitOn hObjectToSignal -- res ) 
Allows the caller to atomically signal an object and wait on another object. 

: OpenSemaphore ( dwDesiredAccess bInheritHandle lpName -- hdnl ) 
Returns a handle of an existing named semaphore object. 

:M CloseSemaphore: 
Closes the semaphore. 

ExclExecute class 
:Class ExclExecute    <Super Object 
To be used to execute a definition in a serial way by using LockExecute: 

int Executing? 
Is true when executing 

Semaphore SemaphoreEntryPoint 
A Semaphore used to lock or unlock an entry point. That will protect definitions that are not able to be executed simultanously It will also protect data against overwriting by another thread while a previous thread still needs that data. 

:M LockExecute: ( cfa - ) 
Locks, executes and unlocks the specified cfa. When more than 1 job try to use LockExecute: at nearly the same time of the same object the second job will be executed after the previous job is ready. 

:M Ready?: ( -- Flag ) 
Returns true when LockExecute: is ready. 

TaskPrimitives class 
:Class TaskPrimitives    <Super ExclExecute 
Contains the general definitions for a task object. In task.f a task in Forth is passed to a thread and when it is complete the task will be destroyed. That takes more than 1.000.000 cycles for each time a task starts. Now a task in Forth will be passed to a job. The Job will be placed in a que of a thread and then be executed. Threads will not be destroyed anymore, they simply wait till an ohter job has been submitted. All Job entries are located in an array starting at &JobBlock. When all job entries are in use and not complete and the next job is submitted, then the system waits till one thread is ready. All parameters for the used threads are located in an array starting at &ThreadBlocks 

Internal parameters defined in the class TaskPrimitives: Name:  Use:  
#threads  -- The maximum number of threads in use in the object.  
/Threadblock  -- The size of one Thread-block.  
&ThreadBlocks  -- The starting address of a threadblock array when it has been allocated.  
OnlyOneThread  -- A flag used to force to use 1 thread only for testing  
LastUsedThreadId  -- Used to a next free thread.  
FoundJobId  -- Keeps the last found free jobID.  
LastUsedJobId  -- Used to find a next free jobID.  
&JobBlock  -- Start address of the JobBlock when it has been allocated.  
#Jobs  -- Number of entries in the JobBlock.  
'CallBack  -- callback function for QueueUserAPC (PAPCFUNC).  
FastJobs  -- If true the elapsed times are diplayed in cycles.  
QueFull  -- Increments when the que is full. Then the system waits at the next job till one thread is ready unless one job gets complete.  

: ResetJob-ThreadID ( - ) 
Set LastUsedJobId and LastUsedThreadId to -1 to reset various ID's 

:M GetQueFull:   ( -- n ) 
Returns the number of times that all job entries are used. 

:M ResetQueFull: ( -- ) 
Set the count of QueFull to 0. 

:M .QueFull:     ( -- ) 
Displays the count of QueFull. 

: JobEntryID>  ( JobEntryAdr - Index ) 
Returns the index of a JobEntry given its address. 

1 CALLBACK: ExecuteJob    { \ #bytes } ( JobEntry -- res ) \ Also defines &ExecuteJob 
Callback fuction for all jobs that are submitted and need no analyzing. 

1 CALLBACK: ExecuteAnalizeJob    { \ #bytes }  ( JobEntry -- res ) \ Also defines &ExecuteAnalizeJob 
Callback fuction for all jobs that are submitted and need to be analyzed. 

:M Set#Jobs: ( n -- ) 
Specify the maximum number of jobs. Set it before starting the object when needed. 

:M Get#Jobs: ( -- n ) 
Get the maximum number of jobs. 

:M GetLockedJobID: ( -- n ) 
Retuns the JobID that is locked 

:M >JobEntry: ( index - adr ) 
Returns the address of a jobentry given its index. 

:M .Jobblock: ( -- ) 
Produces a primitive dump of a jobblock. 

: GetThreadBlock     ( IDindex - ThreadBlock ) 
Returns the address of the threadblock array for its index. 

: tcb>cfa         ( tcb - tcb>cfa ) 
Returns the address of the CFA to be executed from the threadblock. 

: ThreadIndex          ( - #threads 0 ) 
Returns 0 and the maximum number of simultaneously threads in use by the object. 

:M GetThreadcount:  ( -- #threads ) 
Returns the maximum number of simultaneously threads in use. 

:M SetThreadcount:  ( #threads -- ) 
Sets the maximum number of simultaneously threads in use. 

:M Max#threads:     ( -- #threads ) 
Returns the number of hardware threads. 
It returns 2 for older cpu's. 

: CreateRunThread    ( IDindex -- ) 
Creates and runs the thread for windows given the ID and use the parameters of a filled entry in the threadblock. 

:M SuspendThread:      ( IDindex -- ) 
Suspend a thread with the specified ID. 

:M ResumeThread:       ( IDindex -- ) 
Resumes the thread with the specified ID. 

:M SuspendThreads:     ( -- ) 
Suspend all threads in use by the object. 

:M ResumeThreads:      ( -- ) 
Resume all threads in use in the object by the object. 

:M TerminateThread:          ( IDindex -- ) 
To terminate a thread with the specified ID. 
This will also terminate all running jobs of the thread. 

:M TerminateThreads:          ( IDindex -- ) 
Terminates all threads in use in the object by the object. This will also terminate all running jobs in the object. 

:M ReleaseArrays:    ( -- ) 
Release the allocated arrays. 

: MallocJobBlock ( -- ) 
Allocate the needed arrays. 

:M CloseSemaphores: ( -- ) 
Close the semaphores on use by the object. 

: *Canceled* ( ?? - ) 
Resets the stack. *Canceled* is used for reporting. 

: CancelwaitingJob ( index - ) 
Cancel the entry of a job. When a job is running it will continue. 

:M CancelWaitingJobs: ( -- ) 
Cancel waiting and pending jobs of the object. Running Jobs will continue This might give confusing results a job analysis. 

:M TerminateAllJobs: ( -- ) 
Closes all semaphores and terminate all jobs and threads of one object. All waiting jobs will be gone. Use Start: to restart mulitasking again. 

:M UseOneThreadOnly: ( -- ) 
Overwrite the number of simultaneously threads in use by the object. Use it before submitting a job. 

:M UseALLThreads:    ( -- ) 
To overwrite UseOneThreadOnly:. This is default. 

:M GetThreadBlockSize: ( - Size ) 
Returns the threadblock size. 

:M #ActiveThreads:  { \ lpExitCode } ( - #ActiveThreads ) 
Returns the number active threads in the object. 

:M SetThreadBlockSize:  ( NewSize - ) 
Sets a new size for the thread block. 

:M #IncompleteJobs1Thread:  ( index -- #jobs ) 
Returns the number of incomplete jobs of one 1 thread given its ID. 

:M #JobsSubmitted:  ( -- #TotalSubmittedjobs ) 
Returns the total number of submitted jobs in the object. 

:M #IncompleteJobs:  ( -- #Totaljobs ) 
Returns the total number of incomplete jobs in the object. 

:M Ready?:  ( -- flag ) 
Returns true when all jobs are ready. 

:M GetFreeJobId: ( -- Index|-1 ) 
Return an index for a free JobEntry or -1 when it fails. The result is also stored in FoundJobId. 

: AlertableState  ( - ) 
Puts a thread in a alertable state. So it can receive and handle submitted jobs (APC's). 

:M FindThread: { \ cand least } ( -- i ) 
Finds a thread to be used for a job.   
This is done by looking for a waiting thread.  
When there is no thread waiting the thread with the least jobs is returned. Some threads are not as often used as others, since it is faster to find a waiting thread. 

: 5.r ( n - ) 
Display n right justified using 5 positions followed by a space. 

Analyzer tool 
----- Display definitions to be used when the analyzer is ON. -----
(See Analyze:) 

: .JobStatus ( &JobEntry - ) 
Displays the jobstatus of a job given its &JobEntry address. 

: .DifCycles ( startL startH endL endH - ) 
Calculates and displays the difference between a start time and end time in cycles. 

: AverageElapsed \ : ( -- F:AverageInCycles ) 
Calculates the average time In cycles of all jobs in an object. 

: .AverageTime ( F: AverageTime ActTime - ) 
Calculates and displays the relative difference between the average time and actual time of a job. 

:M .JobAnalysis: ( -- ) 
Displays a Job analysis of an object that include elapsed times status and the name of the executed CFA. Note: Job entries can be recycled! 

:M .ThreadBlock: ( - ) 
Displays the number of submitted jobs and the number of completed jobs for each thread of an object. 

:M TimeSeconds: ( -- ) 
Displays the time in seconds in .JobAnalysis:. 

:M TimeCycles: ( -- ) 
Displays the time in cycles in .JobAnalysis:. 

:M AnalyzerOff: ( -- ) 
Puts the analyzer for .JobAnalysis: off. This is default. This will be a bit faster. 

:M EraseStats: ( -- ) 
Erase statistics fome the thread block and Job block of an object. 

----- End of display definitions for the analyzer ----- 

: ExecuteInThread  ( -- ) 
Will run first in any thread. 

:M PrepairThread:   ( cfa IDindex -- ) 
Prepairs a threadblock with various parameters. 

:M StartQueue: ( cfa IDindex -- ) 
Submits the specified cfa in a new thread and returns. 

:M StartQueues: 
Start all queues and threads in an object. All started threads will get in an alertable state and will be ready to receive APC's that use an entry a JobBlock of an object. 

:M MallocThreadArrays: ( -- ) 
Allocates and initializes the ThreadBlock and JobBlock. 

:M Start: ( -- ) 
Used to initialize the object. Must be used before jobs can be submitted 

:M WaitForFreeJobEntry: ( - addr ) 
Waits for a free job entry. When found it will return the addres of the found entry. 

:M LockJobEntry[: ( - ) 
Locks a job entry so it can receive parameters. 

:M ToStack:  ( ni...n0  n --  ) 
To pass n (maximal 8) parameters to the stack of a job. 

:M WaitForAll: ( - ) 
Wait till LockExecute and all Jobs in the object are complete. The definition AlertableState will increase the semaphore when ready. 

: CheckTasbObject ( - ) 
To check if a TasbObject has been started. 

:M Analyze: 
Starts the analyzer for .JobAnalysis: 

:M StopAnalyzing: 
Stops the analyzer. 

:M ClassInit:  ( -- ) 
Initializes the object. Happens automaticly when Forth or a turnkey starts. 

wTasks class 
:Class wTasks    <Super TaskPrimitives 
To run a number of tasks concurrently that can not be indexed. 
Each task is converted to a job. A job can already be complete while the submit action has not yet returned. 

:M ]Submit: ( cfa -- ) 
Submits the specified cfa to a locked JobEntry and return after that job is submitted. 

:M Submit: ( cfa -- ) 
Locks and Submits the specified cfa to a new job and return after that job is submitted. To be used when a job needs no parameters. 

:M ]Single: ( cfa -- ) 
Executes the definition of the specified cfa in the main task. Made for debugging while running in the MainThread. 

:M Single: ( cfa -- ) 
Locks and execute the specified cfa and return after that job is submitted. To be used when a CFA needs no parameters. 

sTask class 
:Class sTask    <Super wTasks 
To run a number of tasks sequentional. 
Each task is converted to a job. All jobs are placed in ONE que for ONE thread. 

iTasks class 
:Class iTasks    <Super TaskPrimitives 
To run ONE definition parallel that contains a do...loop. 
The task is distributed over several jobs and then handeld in one go.  
Each job can get the index for the do...loop by using GetRange:. 
GetThreadIndex can be used to target a value in an array. 

    2 cells bytes TotalRange 
2 cells containing the total of all ranges in the object. | 

:M GetRange:  ( -- High Low ) 
Returns the range to be used before a do...loop of the running job. 

:M Putrange:      ( High Low IDindex -- ) 
Saves the range of a job. 

: .range         ( IDindex - ) 
Show the assigned range of a job using the entry index of the job. 

:M .Ranges: 
Show the ranges of the jobs used by the object. Note: Job entries can be overwritten when they are complete. 

:M SubmitRange:  { High low cfa  -- } 
Submits the specified cfa in a new job and return after that job is submitted. Range and parameters from ToStack: are also passed to the job. 

:M SubmitRanges:  { cfa High low _#threads -- } \ 3 
Distributes and submits all the ranges to various jobs. 

:M SetParallelItems: ( cfa limit IndexLow #threads - ) \ 2 
Initilizes the ranges and submits them. 

:M ]Parallel: \ { limit IndexLow cfa -- }   \ 1 
Submits the specified cfa in a number of jobs. 
Use LockJobEntry[: to lock the entrypoint. The number of jobs depend on the number of hardware threads and the specified range in limit and IndexLow. 
Parallel: returns when all the jobs in the object are complete. 
Each job can get its range by using GetRange:.
Each range can be passed to a do..loop or #do 
The debugger can not be used in a job. 
See Single: for debugging. 

:M Parallel: ( limit IndexLow cfa -- )   \ 1 
Nearly the same as ]Parallel:. Parallel: also uses a lock to prevent nesting while still busy. To be used when no other parameters are passed other than limit IndexLow cfa 

:M Single: ( limit IndexLow cfa -- ) 
Executes the definition of the specified cfa in the main thread. The executed definition can get its range by using GetRange:. Made for debugging while running in the MainThread. 

\s Jos

[toc] | [prev] | [next] | [standalone]

#50595

In article <7600a314-a7c5-4424-9e38-19beb024bc17@googlegroups.com>,
 <josv@planet.nl> wrote:
>On Thursday, September 1, 2016 02:06:13 UTC+2 Paul Rubin wrote:
>
>> foxaudiore...com writes:
>> > I would be interested to see if there is overlap in name choice and
>> > functionality and if others believe we should get some of this
>> > "standardized".
>>=20
>> I had the impression that lots of people have been interested in
>> standardizing multi-tasking, but there was not enough agreement between
>> interested parties to agree on a specification. =20
>>=20
>> It would be nice if you could post some documentation of your word set.
>> I remember being impressed by how simple the eForth multi-tasker is.
>>=20
>> I notice your word set doesn't seem to say anything about communication
>> between tasks, via mailboxes or whatever.
>
>Here is help part of the MultiTaskingClass from Win32Forth
>I hope it is readable since the lines are a bit long:
>
>MultiTaskingClass -- For clustered tasks in objects.=20
>Abstract:=20
>CPU's with multiple cores can execute a program faster than cpu's with a si=
>ngle core.=20
>This is done by breaking up a program in smaller pieces and than execute al=
>l pieces simultaneously.=20
>In multiTaskingClass.f this idea is supported as follows:=20
>Breaking up is possible at the definition level or at the program level by =
>the 2 classes iTask and wTask.=20
>Then the pieces are submitted and simultaneously executed in a number of ta=
>sks.=20
>Tasks are coverted to jobs and clustered in an object for easy access.=20
>
>Objects defined with iTask can be used as soon as ONE definition should be =
>executed in a parallel way and the definition uses a do...loop.=20
>The method Parallel:  divides, distributes and submits for execution the sp=
>ecified cfa over a number of jobs.=20
>A started job can pickup its range for the do...loop part by using the meth=
>od GetRange:.=20
>It is possible to change the number of simultaneous jobs before they run.=
>=20
>
<SNIP> Elaborate description

>
>:M Single: ( limit IndexLow cfa -- )=20
>Executes the definition of the specified cfa in the main thread. The execut=
>ed definition can get its range by using GetRange:. Made for debugging whil=
>e running in the MainThread.=20

That is a lot to take in. What does a simple example look like?

>
>\s Jos

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50596

In article <nq8pm8$ot7$1@cherry.spenarnc.xs4all.nl>,
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>In article <7600a314-a7c5-4424-9e38-19beb024bc17@googlegroups.com>,
> <josv@planet.nl> wrote:
>>On Thursday, September 1, 2016 02:06:13 UTC+2 Paul Rubin wrote:
>>
>>> foxaudiore...com writes:
>>> > I would be interested to see if there is overlap in name choice and
>>> > functionality and if others believe we should get some of this
>>> > "standardized".
>>>=20
>>> I had the impression that lots of people have been interested in
>>> standardizing multi-tasking, but there was not enough agreement between
>>> interested parties to agree on a specification. =20
>>>=20
>>> It would be nice if you could post some documentation of your word set.
>>> I remember being impressed by how simple the eForth multi-tasker is.
>>>=20
>>> I notice your word set doesn't seem to say anything about communication
>>> between tasks, via mailboxes or whatever.
>>
>>Here is help part of the MultiTaskingClass from Win32Forth
>>I hope it is readable since the lines are a bit long:
>>
>>MultiTaskingClass -- For clustered tasks in objects.=20
>>Abstract:=20
>>CPU's with multiple cores can execute a program faster than cpu's with a si=
>>ngle core.=20
>>This is done by breaking up a program in smaller pieces and than execute al=
>>l pieces simultaneously.=20
>>In multiTaskingClass.f this idea is supported as follows:=20
>>Breaking up is possible at the definition level or at the program level by =
>>the 2 classes iTask and wTask.=20
>>Then the pieces are submitted and simultaneously executed in a number of ta=
>>sks.=20
>>Tasks are coverted to jobs and clustered in an object for easy access.=20
>>
>>Objects defined with iTask can be used as soon as ONE definition should be =
>>executed in a parallel way and the definition uses a do...loop.=20
>>The method Parallel:  divides, distributes and submits for execution the sp=
>>ecified cfa over a number of jobs.=20
>>A started job can pickup its range for the do...loop part by using the meth=
>>od GetRange:.=20
>>It is possible to change the number of simultaneous jobs before they run.=
>>=20
>>
><SNIP> Elaborate description
>
>>
>>:M Single: ( limit IndexLow cfa -- )=20
>>Executes the definition of the specified cfa in the main thread. The execut=
>>ed definition can get its range by using GetRange:. Made for debugging whil=
>>e running in the MainThread.=20
>
>That is a lot to take in. What does a simple example look like?

Let me go first with a ciforth example, adding 1 and 2 and faking
that it takes 10 seconds.
------------------------8<--------------------------------------
WANT THREAD-PET -scripting-
VARIABLE RESULT          VARIABLE READY
0 RESULT !
: test 1 2 + 10000 MS ;
: job 0 READY !    test RESULT !    -1 READY ! ;
0 THREAD-PET EXAMPLE
"starting calculation" TYPE CR
' job EXAMPLE
BEGIN READY @ UNTIL
"calculation finished" TYPE CR
RESULT @ .
------------------------8<--------------------------------------

So the job communicates by variables in the main Forth.
This example runs on lina32 and lina64:
    INCLUDE /home/albert/aap.frt
    starting calculation
    calculation finished
    3  OK

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50600

On Thursday, September 1, 2016 at 5:05:25 AM UTC-4, Albert van der Horst wrote:
> In article <nq8pm8$ot7$1@cherry.spenarnc.xs4all.nl>,
> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
> >In article <7600a314-a7c5-4424-9e38-19beb024bc17@googlegroups.com>,
> > <josv@planet.nl> wrote:
> >>On Thursday, September 1, 2016 02:06:13 UTC+2 Paul Rubin wrote:
> >>
> >>> foxaudiore...com writes:
> >>> > I would be interested to see if there is overlap in name choice and
> >>> > functionality and if others believe we should get some of this
> >>> > "standardized".
> >>>=20
> >>> I had the impression that lots of people have been interested in
> >>> standardizing multi-tasking, but there was not enough agreement between
> >>> interested parties to agree on a specification. =20
> >>>=20
> >>> It would be nice if you could post some documentation of your word set.
> >>> I remember being impressed by how simple the eForth multi-tasker is.
> >>>=20
> >>> I notice your word set doesn't seem to say anything about communication
> >>> between tasks, via mailboxes or whatever.
> >>
> >>Here is help part of the MultiTaskingClass from Win32Forth
> >>I hope it is readable since the lines are a bit long:
> >>
> >>MultiTaskingClass -- For clustered tasks in objects.=20
> >>Abstract:=20
> >>CPU's with multiple cores can execute a program faster than cpu's with a si=
> >>ngle core.=20
> >>This is done by breaking up a program in smaller pieces and than execute al=
> >>l pieces simultaneously.=20
> >>In multiTaskingClass.f this idea is supported as follows:=20
> >>Breaking up is possible at the definition level or at the program level by =
> >>the 2 classes iTask and wTask.=20
> >>Then the pieces are submitted and simultaneously executed in a number of ta=
> >>sks.=20
> >>Tasks are coverted to jobs and clustered in an object for easy access.=20
> >>
> >>Objects defined with iTask can be used as soon as ONE definition should be =
> >>executed in a parallel way and the definition uses a do...loop.=20
> >>The method Parallel:  divides, distributes and submits for execution the sp=
> >>ecified cfa over a number of jobs.=20
> >>A started job can pickup its range for the do...loop part by using the meth=
> >>od GetRange:.=20
> >>It is possible to change the number of simultaneous jobs before they run.=
> >>=20
> >>
> ><SNIP> Elaborate description
> >
> >>
> >>:M Single: ( limit IndexLow cfa -- )=20
> >>Executes the definition of the specified cfa in the main thread. The execut=
> >>ed definition can get its range by using GetRange:. Made for debugging whil=
> >>e running in the MainThread.=20
> >
> >That is a lot to take in. What does a simple example look like?
> 
> Let me go first with a ciforth example, adding 1 and 2 and faking
> that it takes 10 seconds.
> ------------------------8<--------------------------------------
> WANT THREAD-PET -scripting-
> VARIABLE RESULT          VARIABLE READY
> 0 RESULT !
> : test 1 2 + 10000 MS ;
> : job 0 READY !    test RESULT !    -1 READY ! ;
> 0 THREAD-PET EXAMPLE
> "starting calculation" TYPE CR
> ' job EXAMPLE
> BEGIN READY @ UNTIL
> "calculation finished" TYPE CR
> RESULT @ .
> ------------------------8<--------------------------------------
> 
> So the job communicates by variables in the main Forth.
> This example runs on lina32 and lina64:
>     INCLUDE /home/albert/aap.frt
>     starting calculation
>     calculation finished
>     3  OK
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

So are you spawning a new instance of CiForth but have a way to read a common variable?

How is the background activity happening?

BF

[toc] | [prev] | [next] | [standalone]

#50604

On Thursday, September 1, 2016 at 11:37:35 AM UTC-5, foxaudio...@gmail.com wrote:
> On Thursday, September 1, 2016 at 5:05:25 AM UTC-4, Albert van der Horst wrote:
> > Let me go first with a ciforth example, adding 1 and 2 and faking
> > that it takes 10 seconds.
> > ------------------------8<--------------------------------------
> > WANT THREAD-PET -scripting-
> > VARIABLE RESULT          VARIABLE READY
> > 0 RESULT !
> > : test 1 2 + 10000 MS ;
> > : job 0 READY !    test RESULT !    -1 READY ! ;
> > 0 THREAD-PET EXAMPLE
> > "starting calculation" TYPE CR
> > ' job EXAMPLE
> > BEGIN READY @ UNTIL
> > "calculation finished" TYPE CR
> > RESULT @ .
> > ------------------------8<--------------------------------------
> > 
> > So the job communicates by variables in the main Forth.
> > This example runs on lina32 and lina64:
> >     INCLUDE /home/albert/aap.frt
> >     starting calculation
> >     calculation finished
> >     3  OK
> > 
> > Groetjes Albert
> > -- 
> > Albert van der Horst, UTRECHT,THE NETHERLANDS
> > Economic growth -- being exponential -- ultimately falters.
> > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
> 
> So are you spawning a new instance of CiForth but have a way to read a common variable?
> 
> How is the background activity happening?
> 
> BF

man 2 clone

It's like fork() with lots of options.  One of them:

CLONE_VM (since Linux 2.0)
  If CLONE_VM is set, the calling process and the child process run in
  the same memory space.  In particular, memory writes performed by
  the calling process or by the child process are also visible in the
  other process.  Moreover, any memory mapping or unmapping performed
  with mmap(2) or munmap(2) by the child or calling process also
  affects the other process.

[toc] | [prev] | [next] | [standalone]

#50608

In article <df47099e-bcad-4f16-8b76-34a95e682a80@googlegroups.com>,
Julian Fondren  <julian.fondren@gmail.com> wrote:
>On Thursday, September 1, 2016 at 11:37:35 AM UTC-5, foxaudio...@gmail.com wrote:
>> On Thursday, September 1, 2016 at 5:05:25 AM UTC-4, Albert van der Horst wrote:
>> > Let me go first with a ciforth example, adding 1 and 2 and faking
>> > that it takes 10 seconds.
>> > ------------------------8<--------------------------------------
>> > WANT THREAD-PET -scripting-
>> > VARIABLE RESULT          VARIABLE READY
>> > 0 RESULT !
>> > : test 1 2 + 10000 MS ;
>> > : job 0 READY !    test RESULT !    -1 READY ! ;
>> > 0 THREAD-PET EXAMPLE
>> > "starting calculation" TYPE CR
>> > ' job EXAMPLE
>> > BEGIN READY @ UNTIL
>> > "calculation finished" TYPE CR
>> > RESULT @ .
>> > ------------------------8<--------------------------------------
>> >
>> > So the job communicates by variables in the main Forth.
>> > This example runs on lina32 and lina64:
>> >     INCLUDE /home/albert/aap.frt
>> >     starting calculation
>> >     calculation finished
>> >     3  OK
>> >
>> > Groetjes Albert
>> > --
>> > Albert van der Horst, UTRECHT,THE NETHERLANDS
>> > Economic growth -- being exponential -- ultimately falters.
>> > albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
>>
>> So are you spawning a new instance of CiForth but have a way to read a common variable?
>>
>> How is the background activity happening?
>>
>> BF
>
>man 2 clone
>
>It's like fork() with lots of options.  One of them:
>
>CLONE_VM (since Linux 2.0)
>  If CLONE_VM is set, the calling process and the child process run in
>  the same memory space.  In particular, memory writes performed by
>  the calling process or by the child process are also visible in the
>  other process.  Moreover, any memory mapping or unmapping performed
>  with mmap(2) or munmap(2) by the child or calling process also
>  affects the other process.

The combination of flags also result that file descriptors are kept in
the thread. A thread can TYPE all right, but it gets mixed on the
screen with the output of the main program. Very short code, much
stuff to sort out.

Let me add the second part of the story.
ciforth has a traditional setup with user variables. One of those is
CONTEXT the list of wid's to inspect. A wordlist is a linked list.
A thread will have its words link to the main vocabulary so it
can access all words that were there before its existance,
including its VARIABLE's. It will have a separate HERE pointer and
words compiled in a thread appear in the thread only.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50602

Le jeudi 1 septembre 2016 11:05:25 UTC+2, Albert van der Horst a écrit :
> 
> Let me go first with a ciforth example, adding 1 and 2 and faking
> that it takes 10 seconds.
> ------------------------8<--------------------------------------
> WANT THREAD-PET -scripting-
> VARIABLE RESULT          VARIABLE READY
> 0 RESULT !
> : test 1 2 + 10000 MS ;
> : job 0 READY !    test RESULT !    -1 READY ! ;
> 0 THREAD-PET EXAMPLE
> "starting calculation" TYPE CR
> ' job EXAMPLE
> BEGIN READY @ UNTIL
> "calculation finished" TYPE CR
> RESULT @ .
> ------------------------8<--------------------------------------
> 
> So the job communicates by variables in the main Forth.
> This example runs on lina32 and lina64:
>     INCLUDE /home/albert/aap.frt
>     starting calculation
>     calculation finished
>     3  OK
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Probably not suitable as it runs on top of an OS, but here is how it can 
be done in Oforth : 

import: parallel
Channel new const: MailBox

: job  1 2 + 10000 sleep MailBox send drop ;

#job &
MailBox receive .

[toc] | [prev] | [next] | [standalone]

#50597

> That is a lot to take in
The extension was written because Forth was not able to use all
the hardware threads of my PC at that time.

>Objects defined with iTask can be used as soon as ONE definition should be
>executed in a parallel way and the definition uses a do...loop.
>The method Parallel:  divides, distributes and submits for execution the
>specified cfa over a number of jobs.
>A started job can pickup its range for the do...loop part by using the
> method GetRange:.
>It is possible to change the number of simultaneous jobs before they run
>
<SNIP> Elaborate description

By default the object will use all the available hardware threads in one
object. If you do not want that than you can modify the number of hardware
threads used in an object.
With GetRange: you can get an index which can be used to point a location
in an array.

A simple demo using your example:

needs MultiTaskingClass.f \ Of Win32Forth Version: 6.15.04

wTasks myTasks     \ Make the object myTasks.
VARIABLE RESULT    VARIABLE READY   0 RESULT !
: test 1 2 + 10000 MS ;
: jobDemo 0 READY !    test RESULT !    -1 READY ! ;

Start: myTasks \ Initializes the object.

cr .( Starting calculation)

' jobDemo Submit: myTasks
WaitForAll: myTasks

cr .( Calculation finished )
RESULT @ .

\s
Demo's for Parallel: can be found at the end of MultiTaskingClass.f
Jos

On Thursday, September 1, 2016 10:34:32 UTC+2 Albert van der Horst wrote:
> In article <7600a...googlegroups.com>,
>  <jos...net.nl> wrote:
> >On Thursday, September 1, 2016 02:06:13 UTC+2 Paul Rubin wrote:
> >
> >> foxaudiore...com writes:
> >> > I would be interested to see if there is overlap in name choice and
> >> > functionality and if others believe we should get some of this
> >> > "standardized".
> >>=20
> >> I had the impression that lots of people have been interested in
> >> standardizing multi-tasking, but there was not enough agreement between
> >> interested parties to agree on a specification. =20
> >>=20
> >> It would be nice if you could post some documentation of your word set.
> >> I remember being impressed by how simple the eForth multi-tasker is.
> >>=20
> >> I notice your word set doesn't seem to say anything about communication
> >> between tasks, via mailboxes or whatever.
> >
> >Here is help part of the MultiTaskingClass from Win32Forth
> >I hope it is readable since the lines are a bit long:
> >
> >MultiTaskingClass -- For clustered tasks in objects.=20
> >Abstract:=20
> >CPU's with multiple cores can execute a program faster than cpu's with a si=
> >ngle core.=20
> >This is done by breaking up a program in smaller pieces and than execute al=
> >l pieces simultaneously.=20
> >In multiTaskingClass.f this idea is supported as follows:=20
> >Breaking up is possible at the definition level or at the program level by =
> >the 2 classes iTask and wTask.=20
> >Then the pieces are submitted and simultaneously executed in a number of ta=
> >sks.=20
> >Tasks are coverted to jobs and clustered in an object for easy access.=20
> >
> >Objects defined with iTask can be used as soon as ONE definition should be =
> >executed in a parallel way and the definition uses a do...loop.=20
> >The method Parallel:  divides, distributes and submits for execution the sp=
> >ecified cfa over a number of jobs.=20
> >A started job can pickup its range for the do...loop part by using the meth=
> >od GetRange:.=20
> >It is possible to change the number of simultaneous jobs before they run.=
> >=20
> >
> <SNIP> Elaborate description
> 
> >
> >:M Single: ( limit IndexLow cfa -- )=20
> >Executes the definition of the specified cfa in the main thread. The execut=
> >ed definition can get its range by using GetRange:. Made for debugging whil=
> >e running in the MainThread.=20
> 
> That is a lot to take in. What does a simple example look like?
> 
> >
> >\s Jos
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50598

On Wednesday, August 31, 2016 at 8:06:13 PM UTC-4, Paul Rubin wrote:
> foxaudioresearch@gmail.com writes:
> > I would be interested to see if there is overlap in name choice and
> > functionality and if others believe we should get some of this
> > "standardized".
> 
> I had the impression that lots of people have been interested in
> standardizing multi-tasking, but there was not enough agreement between
> interested parties to agree on a specification.  
> 
> It would be nice if you could post some documentation of your word set.
> I remember being impressed by how simple the eForth multi-tasker is.
> 
> I notice your word set doesn't seem to say anything about communication
> between tasks, via mailboxes or whatever.

I will have to write up docs.  This tasker is a re-work of HsForth for DOS and
it's a hobby system.  I have built another from scratch for MaxForth on 68HC11.
They are all very similar I believe and leverage ideas from the original Forth
Inc. multi-tasker system.

By adding a new USER variable called TASK-MAIL I used this old concept for 
inter-task communication. Not fancy but it met my needs.

\ Simple mailbox implementation for Fox Multi-tasker. (MaxForth) 04JAN94)
\ base on article in Forth Dimensions Vol 7 #4 by R. W. Dobbins. Columbia ML.
\ It allows a transputer like com link between FORTH tasks.
\ Concept: "SENDer" waits until the mailbox is cleared by "RECIEVER" before 
\ sending the next message.
\ Message is 1 CELL.  But complex sender/receiver pairs can be created with 
\ this simple pipe.

\ *** LIMITED TO NON-ZERO VALUES.  

\ see demo\taskmail.hsf

: SEND-MAIL      ( msg rcvr-PID --)
                 TASK-MAIL LOCAL   \ ( msg addr ) compute rcvr mailbox address
                 BEGIN
                    PAUSE
                    DUP@           \ ( msg addr n )  n = contents of mailbox
                 0= UNTIL          \ ( msg addr ) loop until mailbox is empty
                 ! ;               \ store the msg in addr

: READ-MAIL     ( PID -- msg )     \ read mail from any task
                 TASK-MAIL LOCAL   \ ( -- addr )
                 BEGIN
                   PAUSE
                   DUP@            \ dup the addr and fetch contents
                 ?DUP UNTIL        \ loop until content is not zero
                 0 ROT ! ;         \ put zero in the mail box, msg on stack


: GET-MAIL      ( -- n )  myself read-mail ;

BF

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web