![]() |
||
| Home | SwiftForth Archive | SwiftX Archive | |

Pedro,
Bob, although he declines to admit it, was dead on. The problem is
that you are running a task instead of a thread. Windows OS is designed
for pre-emptive multitasking; FORTH historically was not. The original
goal in SwiftForth was to maintain that historical compatability, and
it was a difficult fit. As a result, using a TASK is a poor way to share
the cpu resource in a single application. This is why I implemented
the FORKS> concept.
A thread, especially one that waits for a serial character to arrive
by using a blocking read operation, will be extremely efficient in
both cpu usage and response time.
Rick
On Thu, 26 Jun 2003 13:44:41 -0700, Bob Nash <BNash_at_smud.org> wrote:
> Tasks vs. Threads -- no, not suggesting that is the problem, but a =
> better way to go. FYI, TASK allocates a minimum of 16,384. I don't =
> think priority is the problem.
>
> -----Original Message-----
> From: Pedro Monteiro [mailto:pm_at_entropylock.com]
> Sent: Thursday, June 26, 2003 1:32 PM
> To: sftalk_at_forth.com
> Subject: [sftalk] Re: Background COM port task very slow
>
>
> The background task had a Sleep in it, but I removed it when things were
> running slowly, and relied instead upon the PAUSE inside (COM-KEY). It
> seems to have not made a difference.
>
> Yes, I am running this from the console, and I do plan to port it to a
> turnkey app. On your suggestion, I am looking into using threads instead
> of tasks.=20
>
> Are you suggesting that a Thread will run faster than a TASK? Why is the
> task so slow? Did I overlook something, or are TASKs this slow by
> default, and I must use some mystery words to speed my TASK up (e.g.
> change the thread priority)?
>
> Thanks for your help,
> Pedro
>
> -----Original Message-----
> From: sftalk-bounce_at_forth.com [mailto:sftalk-bounce_at_forth.com] On Behalf
> Of Bob Nash
> Sent: Thursday, June 26, 2003 3:48 PM
> To: sftalk_at_forth.com
> Subject: [sftalk] Re: Background COM port task very slow
>
>
> I assume GET-1GPS-REC in the background task has a sleep (or a timed =3D
> character wait with a sleep) in it. You are running this from the =3D
> console, right? Suggest using forks> and TerminateThread for turnkeyed
> =3D app.
>
> -----Original Message-----
> From: Pedro Monteiro [mailto:pm_at_entropylock.com]
> Sent: Thursday, June 26, 2003 11:56 AM
> To: sftalk_at_forth.com
> Subject: [sftalk] Background COM port task very slow
>
>
> Problem:
> TASK runs too slowly in background, but runs fine in foreground. I will
> be grateful for any advice.
>
> I have a background task that monitors the COM port for GPS data, and
> parses it into variables. When I run the parser in the foreground, the
> variables are updated as they become available on the COM port. However,
> when I run the same parser code in the background, the variables are
> updated once every two or three seconds. The serial buffer then grows in
> size, filling up with a backlog of COM port data that the GPS sent once
> per second.
>
> If I instead run the parser in the foreground, it quickly reads the
> backlogged COM port data, catching up to the real-time GPS records.
>
> - The GPS data is less than 400 bytes, sent at 9,600 baud, once each
> second.
> - SwiftForth 2.2.2.9 07May2001
> - Windows 2000
> - Reading COM port with COM-KEY from SIO.F
> - Processor usage is around 5% with background parser running.
> - A foreground task that prints the parsed variables to the SwiftForth
> console raises to 100%, when the parser is running in the FOREGROUND.
> - A foreground task that prints the parsed variables to the SwiftForth
> console varies between 70-100%, when the parser is running in the
> BACKGROUND.
> - While the foreground process is not running, the background process
> should catch up to the data with no display semaphores to possibly slow
> it down. In any case, commenting out the semaphores did not change the
> update rate.=3D20
>
> The code below shows that both the foreground word (GFR)=3D20
> and the background word (START-GPS-MONITOR)=3D20
> call the same GPS parser code (GET1GPS-REC).
>
> Could the Windows process priority be set too low? How do I change
> it?=3D20 How do I get GPS-MONITOR to be listed in Windows Task Manager?
>
> Any advice will be greatly appreciated. Thanks,
> - Pedro
>
> ----------------------------------------------------------
> : GFR ( -- ) \ get GPS record then print until key pressed
> ZERO-COUNTERS
> BEGIN
> GET1GPS-REC
> .GPS-RECS
> EKEY? UNTIL
> ; \ GPS-FIND-REC
>
> 8192 TASK GPS-MONITOR \ set up a background task
>
> : START-GPS-MONITOR ( -- ) \ parse each record from GPS into vars until
> killed
> ZERO-COUNTERS
> GPS-MONITOR ACTIVATE=3D20
> BEGIN
> GET1GPS-REC
> AGAIN
> ; \ START-GPS-MONITOR=3D20
>
> : .GPS ( -- ) \ getting GPS record in background. Now print until key
> pressed
> 0 GPSUPDATE# !
> BEGIN
> .GPS-RECS
> GPSUPDATE# @ 1+ DUP CR . GPSUPDATE# !
> 200 Sleep DROP
> EKEY? UNTIL
> ;
>
> ----------------------------------------------------------------------
> sftalk_at_forth.com The SwiftForth programming discussion email list
> To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
> For list command help, send subject "help" to sftalk-request_at_forth.com
> Message archives are located at http://www.forth.com/archive/sftalk
> ----------------------------------------------------------------------
> This list is a forum for SwiftForth users. For product support and
> bug=20
> reports, please send email to support_at_forth.com
> ----------------------------------------------------------------------
>
> ----------------------------------------------------------------------
> sftalk_at_forth.com The SwiftForth programming discussion email list
> To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
> For list command help, send subject "help" to sftalk-request_at_forth.com
> Message archives are located at http://www.forth.com/archive/sftalk
> ----------------------------------------------------------------------
> This list is a forum for SwiftForth users. For product support and bug
> reports, please send email to support_at_forth.com
> ----------------------------------------------------------------------
>
>
----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Thu Jun 26 2003 - 14:10:14 PDT
This archive was generated by hypermail 2.2.0 : Tue Dec 02 2008 - 03:04:32 PST