Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56858 > unrolled thread
| Started by | "HAA" <someone@microsoft.com> |
|---|---|
| First post | 2017-04-08 20:53 +1000 |
| Last post | 2017-04-10 07:42 -1000 |
| Articles | 20 on this page of 151 — 21 participants |
Back to article view | Back to comp.lang.forth
polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-08 20:53 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-08 12:29 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 09:50 +1000
Re: polyForth multitasker question David Schultz <abuse@127.0.0.1> - 2017-04-09 19:25 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 10:52 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 08:58 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-15 10:39 +1000
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 11:12 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-10 18:22 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:17 +1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-11 03:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 14:37 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-09 18:05 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 15:50 -1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-10 07:47 +0200
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-10 12:20 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 09:11 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 04:20 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 10:53 +0100
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-10 11:24 +0100
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-11 12:05 +1000
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-11 14:27 +0100
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 07:08 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-11 18:06 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-11 18:58 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 13:57 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 18:02 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-12 19:47 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-12 21:22 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 02:57 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-12 23:17 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 00:13 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:43 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-13 19:34 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 19:57 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 02:45 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 21:28 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 07:53 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:44 -0700
Re: polyForth multitasker question minforth@arcor.de - 2017-04-14 02:01 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:28 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:23 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:46 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 11:31 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 11:23 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:06 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 08:13 -0500
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-14 14:12 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-14 09:30 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 08:46 +0000
Re: polyForth multitasker question pahihu <pahihu@gmail.com> - 2017-04-15 13:07 -0700
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:27 -0700
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 18:18 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 13:53 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-14 11:34 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 11:31 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-14 12:14 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:46 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:48 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 12:50 -0700
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:39 +0200
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-15 11:48 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 22:07 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 16:47 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 11:36 -1000
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-15 17:07 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-15 14:17 -1000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 18:27 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 06:53 +0300
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 22:00 -0700
Re: polyForth multitasker question Ron Aaron <rambamist@gmail.com> - 2017-04-16 08:59 +0300
Re: polyForth multitasker question lehs <skydda.barnen@gmail.com> - 2017-04-15 22:19 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-15 17:26 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 09:10 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:13 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:28 +0000
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 09:27 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-16 14:45 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-16 17:50 -1000
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 12:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 13:27 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 03:49 -0500
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-18 13:47 +0100
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 14:30 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 20:58 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-18 11:47 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-17 19:19 -0700
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-18 04:34 -0500
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 02:00 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 18:10 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-19 01:41 -0700
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 21:38 +1000
Re: polyForth multitasker question Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-19 10:56 +0200
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-19 07:22 -0500
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:10 -0700
Re: polyForth multitasker question stephen@mpeforth.com (Stephen Pelc) - 2017-04-18 09:35 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-18 08:01 -0700
Re: polyForth multitasker question Julian Fondren <julian.fondren@gmail.com> - 2017-04-18 09:03 -0700
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 11:07 -0500
Re: polyForth multitasker question Cecil Bayona <cbayona@cbayona.com> - 2017-04-18 10:59 -0500
Re: polyForth multitasker question "HAA" <someone@microsoft.com> - 2017-04-19 19:13 +1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:36 -0700
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 16:27 +0000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-16 04:32 -0500
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 10:15 -1000
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 13:07 +0200
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 15:13 +0000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 01:36 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 22:48 -1000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 16:36 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 14:55 -0700
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 15:27 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-14 23:45 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-16 21:13 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-17 16:57 +0100
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-17 20:08 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 20:29 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-14 15:34 -1000
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 19:43 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:03 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-14 23:50 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 03:55 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 01:38 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 11:50 -0400
Re: polyForth multitasker question john <anon@example.com> - 2017-04-15 12:03 +0100
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-15 12:41 +0000
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:14 -0400
Re: polyForth multitasker question Paul Rubin <no.email@nospam.invalid> - 2017-04-15 17:32 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 20:41 -0400
Re: polyForth multitasker question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 14:57 +0000
Re: polyForth multitasker question hughaguilar96@gmail.com - 2017-04-14 20:45 -0700
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-14 23:56 -0400
Re: polyForth multitasker question albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:32 +0200
Re: polyForth multitasker question rickman <gnuarm@gmail.com> - 2017-04-15 12:05 -0400
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-15 04:10 -0500
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-13 03:19 -0700
Re: polyForth multitasker question Alex <alex@rivadpm.com> - 2017-04-13 15:46 +0100
Re: polyForth multitasker question foxaudioresearch@gmail.com - 2017-04-14 11:37 -0700
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-13 09:48 -1000
Re: polyForth multitasker question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 05:37 -0500
Re: polyForth multitasker question minforth@arcor.de - 2017-04-11 22:12 -0700
Multitasking with Forth processors Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 07:39 +0200
Re: Multitasking with Forth processors Paul Rubin <no.email@nospam.invalid> - 2017-04-11 22:58 -0700
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 03:00 -0400
Re: Multitasking with Forth processors albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-12 12:18 +0200
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-12 17:11 -0400
Re: Multitasking with Forth processors foxaudioresearch@gmail.com - 2017-04-12 13:50 -0700
Re: Multitasking with Forth processors "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 13:30 -1000
Re: Multitasking with Forth processors Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-14 12:20 +0100
Re: Multitasking with Forth processors rickman <gnuarm@gmail.com> - 2017-04-14 16:47 -0400
Re: polyForth multitasker question "Elizabeth D. Rather" <erather@forth.com> - 2017-04-10 07:42 -1000
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-08 20:53 +1000 |
| Subject | polyForth multitasker question |
| Message-ID | <ocafkt$1929$1@gioia.aioe.org> |
In the PF manual (electronic version from Greenarrays) Fig. 4.1 shows the
following events. In no particular order ...
1. Executing PAUSE explicitly sets the current task's status to 'wake' before
looking for the next active task.
2. When the next active task is found, that task's status is set to 'sleep' before
control is passed to it.
3. STOP/WAIT executes PAUSE with the exception the current task's status
is unchanged (or so Fig 4.1 depicts).
Can someone confirm whether the sole purpose of (2) in setting status
to 'sleep' was so that STOP/WAIT would work properly? Or does setting
the 'sleep' status for running tasks have other purposes? I ask this
because other Forth taskers I've seen don't do any of this status juggling.
[toc] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-08 12:29 -0500 |
| Message-ID | <koGdneROYv-Yg3TFnZ2dnUU7-KvNnZ2d@supernews.com> |
| In reply to | #56858 |
HAA <someone@microsoft.com> wrote: > In the PF manual (electronic version from Greenarrays) Fig. 4.1 shows the > following events. In no particular order ... > > 1. Executing PAUSE explicitly sets the current task's status to 'wake' before > looking for the next active task. > > 2. When the next active task is found, that task's status is set to 'sleep' before > control is passed to it. > > 3. STOP/WAIT executes PAUSE with the exception the current task's status > is unchanged (or so Fig 4.1 depicts). > > Can someone confirm whether the sole purpose of (2) in setting > status to 'sleep' was so that STOP/WAIT would work properly? Or > does setting the 'sleep' status for running tasks have other > purposes? I ask this because other Forth taskers I've seen don't do > any of this status juggling. It's important that wakeups don't get lost. A task which executes STOP in order to wait for an event has to be able to cope with an event which happens *before* STOP is executed. Imagine this: send stop receive If the other end of the connection is *really* fast, some data might have been received (and the wakeup sent) before the STOP . So, when a task is run, its status is first set to sleep: thereafter, that task can be awoken at any time, and the wakeup won't be lost. If you do it any other way you have a race condition where you can lose wakeups. Semantically, its logic is almost identical to Java's LockSupport class (at https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/LockSupport.html). Java's park() is STOP, its unpark(Thread) is a wakeup. Forth's STATUS field is what Java calls a permit. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-10 09:50 +1000 |
| Message-ID | <ocehe0$19ks$1@gioia.aioe.org> |
| In reply to | #56874 |
Andrew Haley wrote: > HAA <someone@microsoft.com> wrote: > > In the PF manual (electronic version from Greenarrays) Fig. 4.1 shows the > > following events. In no particular order ... > > > > 1. Executing PAUSE explicitly sets the current task's status to 'wake' before > > looking for the next active task. > > > > 2. When the next active task is found, that task's status is set to 'sleep' before > > control is passed to it. > > > > 3. STOP/WAIT executes PAUSE with the exception the current task's status > > is unchanged (or so Fig 4.1 depicts). > > > > Can someone confirm whether the sole purpose of (2) in setting > > status to 'sleep' was so that STOP/WAIT would work properly? Or > > does setting the 'sleep' status for running tasks have other > > purposes? I ask this because other Forth taskers I've seen don't do > > any of this status juggling. > > It's important that wakeups don't get lost. A task which executes > STOP in order to wait for an event has to be able to cope with an > event which happens *before* STOP is executed. Imagine this: > > send stop receive > > If the other end of the connection is *really* fast, some data might > have been received (and the wakeup sent) before the STOP . So, when a > task is run, its status is first set to sleep: thereafter, that task > can be awoken at any time, and the wakeup won't be lost. If you do it > any other way you have a race condition where you can lose wakeups. > > Semantically, its logic is almost identical to Java's LockSupport > class (at > https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/LockSupport.html). > Java's park() is STOP, its unpark(Thread) is a wakeup. Forth's STATUS > field is what Java calls a permit. > > Andrew. It would explain why Forth Inc STOP doesn't explicitly 'sleep' a task. Does anyone have sample code that potentially allows a task to receive a wakeup before STOP is encountered? Such code would break the F83 tasker and possibly others.
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <abuse@127.0.0.1> |
|---|---|
| Date | 2017-04-09 19:25 -0500 |
| Message-ID | <osqdnXE4nqyfTHfFnZ2dnUU7-TPNnZ2d@earthlink.com> |
| In reply to | #56951 |
On 04/09/2017 06:50 PM, HAA wrote: > It would explain why Forth Inc STOP doesn't explicitly 'sleep' a task. > Does anyone have sample code that potentially allows a task to receive > a wakeup before STOP is encountered? Such code would break the > F83 tasker and possibly others. > All it takes is for interrupts to be used. If an ISR can cause a WAKE, that can happen at any time. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-10 10:52 +1000 |
| Message-ID | <ocel17$1e3r$1@gioia.aioe.org> |
| In reply to | #56953 |
David Schultz wrote: > On 04/09/2017 06:50 PM, HAA wrote: > > It would explain why Forth Inc STOP doesn't explicitly 'sleep' a task. > > Does anyone have sample code that potentially allows a task to receive > > a wakeup before STOP is encountered? Such code would break the > > F83 tasker and possibly others. > > > > All it takes is for interrupts to be used. If an ISR can cause a WAKE, > that can happen at any time. I wonder then how the F83 tasker would deal with it. I assume the F83 tasker has been used commercially. Examples of Forth multitasking application code in the public domain are hard to find.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-10 08:58 -0500 |
| Message-ID | <MuqdnR1xr70CEnbFnZ2dnUU7-bnNnZ2d@supernews.com> |
| In reply to | #56958 |
HAA <someone@microsoft.com> wrote: > David Schultz wrote: >> On 04/09/2017 06:50 PM, HAA wrote: >> > It would explain why Forth Inc STOP doesn't explicitly 'sleep' a >> > task. Does anyone have sample code that potentially allows a >> > task to receive a wakeup before STOP is encountered? Such code >> > would break the F83 tasker and possibly others. >> >> All it takes is for interrupts to be used. If an ISR can cause a WAKE, >> that can happen at any time. > > I wonder then how the F83 tasker would deal with it. I don't think it would. It's obviously wrong, and would lose wakeups. My best guess is that if anybody used F83 for real on anything other than a purely OS-hostsed system this bug would have been found and fixed. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-15 10:39 +1000 |
| Message-ID | <ocrq5l$4n1$1@gioia.aioe.org> |
| In reply to | #56997 |
Andrew Haley wrote: > HAA <someone@microsoft.com> wrote: > > David Schultz wrote: > >> On 04/09/2017 06:50 PM, HAA wrote: > >> > It would explain why Forth Inc STOP doesn't explicitly 'sleep' a > >> > task. Does anyone have sample code that potentially allows a > >> > task to receive a wakeup before STOP is encountered? Such code > >> > would break the F83 tasker and possibly others. > >> > >> All it takes is for interrupts to be used. If an ISR can cause a WAKE, > >> that can happen at any time. > > > > I wonder then how the F83 tasker would deal with it. > > I don't think it would. It's obviously wrong, and would lose wakeups. > > My best guess is that if anybody used F83 for real on anything other > than a purely OS-hostsed system this bug would have been found and > fixed. > > Andrew. Not just F83. Every non Forth Inc multitasker I've seen to date, including commercials, would exhibit this problem. Users have either been lucky and not encountered wakeup before stop, or they've managed to avoid it. Perhaps users and vendors of those systems can comment.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-11 11:12 +1000 |
| Message-ID | <ochajl$1oep$1@gioia.aioe.org> |
| In reply to | #56953 |
David Schultz wrote: > On 04/09/2017 06:50 PM, HAA wrote: > > It would explain why Forth Inc STOP doesn't explicitly 'sleep' a task. > > Does anyone have sample code that potentially allows a task to receive > > a wakeup before STOP is encountered? Such code would break the > > F83 tasker and possibly others. > > > > All it takes is for interrupts to be used. If an ISR can cause a WAKE, > that can happen at any time. Still can't think of a situation of a task receiving a WAKE before STOP that doesn't boil down to poor design. As I don't work with controllers, can someone present a realistic scenario where it could occur?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-10 18:22 -0700 |
| Message-ID | <87zifn68mf.fsf@nightsong.com> |
| In reply to | #57027 |
"HAA" <someone@microsoft.com> writes: > Still can't think of a situation of a task receiving a WAKE before STOP Interrupts are completely asynchronous to the program. So the abstraction of cooperative multitasking breaks down when interrupts are in play. If the interrupt can WAKE, you face the same hazards in their presence as you do in preemptive multitasking. I would have imagined that the ISR sets a flag that the scheduler checks during task switch.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-11 12:17 +1000 |
| Message-ID | <ochecm$1s46$1@gioia.aioe.org> |
| In reply to | #57028 |
Paul Rubin wrote: > "HAA" <someone@microsoft.com> writes: > > Still can't think of a situation of a task receiving a WAKE before STOP > > Interrupts are completely asynchronous to the program. So the > abstraction of cooperative multitasking breaks down when interrupts are > in play. If the interrupt can WAKE, you face the same hazards in their > presence as you do in preemptive multitasking. I would have imagined > that the ISR sets a flag that the scheduler checks during task switch. We're talking about interrupts that are designed to work with a task, understanding the task may be slow or must complete what it's currently doing. I don't see how a WAKE before STOP could occur in that case.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-11 03:10 -0500 |
| Message-ID | <btGdnQUb-b4bEnHFnZ2dnUU7-T3NnZ2d@supernews.com> |
| In reply to | #57027 |
HAA <someone@microsoft.com> wrote: > David Schultz wrote: >> On 04/09/2017 06:50 PM, HAA wrote: >> > It would explain why Forth Inc STOP doesn't explicitly 'sleep' a task. >> > Does anyone have sample code that potentially allows a task to receive >> > a wakeup before STOP is encountered? Such code would break the >> > F83 tasker and possibly others. >> > >> >> All it takes is for interrupts to be used. If an ISR can cause a WAKE, >> that can happen at any time. > > Still can't think of a situation of a task receiving a WAKE before > STOP that doesn't boil down to poor design. Oh, that's super-easy to describe. Say you have an interrupt-driven serial port. The way to transmit a string is to write a byte to the output buffer and then write all subsequent bytes during the TX interrupt routine. When the last byte is written, the interrupt routine returns without writing anything. If the UART has an output buffer, the first TX interrupt happens the instant after you write the initial byte. There's obviously a race between that interrupt happening and the task stopping. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-09 14:37 -1000 |
| Message-ID | <CM2dnXuhx9lfTnfFnZ2dnUU7-TfNnZ2d@supernews.com> |
| In reply to | #56951 |
On 4/9/17 1:50 PM, HAA wrote: > Andrew Haley wrote: >> HAA <someone@microsoft.com> wrote: >>> In the PF manual (electronic version from Greenarrays) Fig. 4.1 shows the >>> following events. In no particular order ... >>> >>> 1. Executing PAUSE explicitly sets the current task's status to 'wake' before >>> looking for the next active task. >>> >>> 2. When the next active task is found, that task's status is set to 'sleep' before >>> control is passed to it. >>> >>> 3. STOP/WAIT executes PAUSE with the exception the current task's status >>> is unchanged (or so Fig 4.1 depicts). >>> >>> Can someone confirm whether the sole purpose of (2) in setting >>> status to 'sleep' was so that STOP/WAIT would work properly? Or >>> does setting the 'sleep' status for running tasks have other >>> purposes? I ask this because other Forth taskers I've seen don't do >>> any of this status juggling. >> >> It's important that wakeups don't get lost. A task which executes >> STOP in order to wait for an event has to be able to cope with an >> event which happens *before* STOP is executed. Imagine this: >> >> send stop receive >> >> If the other end of the connection is *really* fast, some data might >> have been received (and the wakeup sent) before the STOP . So, when a >> task is run, its status is first set to sleep: thereafter, that task >> can be awoken at any time, and the wakeup won't be lost. If you do it >> any other way you have a race condition where you can lose wakeups. >> >> Semantically, its logic is almost identical to Java's LockSupport >> class (at >> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/LockSupport.html). >> Java's park() is STOP, its unpark(Thread) is a wakeup. Forth's STATUS >> field is what Java calls a permit. >> >> Andrew. > > It would explain why Forth Inc STOP doesn't explicitly 'sleep' a task. > Does anyone have sample code that potentially allows a task to receive > a wakeup before STOP is encountered? Such code would break the > F83 tasker and possibly others. In many applications, there's nothing wrong with letting the multitasker spin when nothing's going on, because in a PC, for example, it doesn't cost any extra power. The cost is one machine instruction per task. Typically putting a task to sleep is 3-4 machine instructions, and waking the next one up maybe 5-6, so the whole thing is really pretty efficient compared with conventional multitaskers. Battery-operated microcontrollers are a different matter, of course, but most of them have provision for a "sleep mode". On the MSP430, for example, SwiftX will go to sleep mode if no tasks are active, waking when an interrupt signals something to do. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-09 18:05 -0700 |
| Message-ID | <87fuhh8425.fsf@nightsong.com> |
| In reply to | #56956 |
"Elizabeth D. Rather" <erather@forth.com> writes: > In many applications, there's nothing wrong with letting the > multitasker spin when nothing's going on, because in a PC, for > example, it doesn't cost any extra power. PC's nowadays use a lot more power when the cpu is busy. If something gets caught in a loop on my laptop, I can tell that it happens because the laptop fan turns on. With my old laptop, if I ran something compute-intensive, the laptop itself would start to smell bad after a while, as heat buildup caused internal adhesives and stuff to off-gas. See also: https://xkcd.com/1172/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-09 15:50 -1000 |
| Message-ID | <VJydnVqJkI1neXfFnZ2dnUU7-f_NnZ2d@supernews.com> |
| In reply to | #56959 |
On 4/9/17 3:05 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> In many applications, there's nothing wrong with letting the >> multitasker spin when nothing's going on, because in a PC, for >> example, it doesn't cost any extra power. > > PC's nowadays use a lot more power when the cpu is busy. If something > gets caught in a loop on my laptop, I can tell that it happens because > the laptop fan turns on. With my old laptop, if I ran something > compute-intensive, the laptop itself would start to smell bad after a > while, as heat buildup caused internal adhesives and stuff to off-gas. > > See also: https://xkcd.com/1172/ In the 70's and 80's, power consumption (as well as performance) was dominated by the amount of disk access, which is why polyFORTH paid a lot of attention to designing the block handling scheme so as to minimize disk access. Nowadays many systems have only solid-state mass storage. As the architecture changes, so do the tradeoffs! Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-04-10 07:47 +0200 |
| Message-ID | <8660iczue5.fsf@molnjunk.nocrew.org> |
| In reply to | #56959 |
Paul Rubin <no.email@nospam.invalid> writes: > With my old laptop, if I ran something compute-intensive, the laptop > itself would start to smell bad after a while, An olfactory user interface, I'm impressed! I think SmellForth has the potential to obsolete ColorForth.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-10 12:20 +1000 |
| Message-ID | <oceq7n$1kme$1@gioia.aioe.org> |
| In reply to | #56956 |
Elizabeth D. Rather wrote: > ... > In many applications, there's nothing wrong with letting the multitasker > spin when nothing's going on, because in a PC, for example, it doesn't > cost any extra power. The cost is one machine instruction per task. > Typically putting a task to sleep is 3-4 machine instructions, and > waking the next one up maybe 5-6, so the whole thing is really pretty > efficient compared with conventional multitaskers. > > Battery-operated microcontrollers are a different matter, of course, but > most of them have provision for a "sleep mode". On the MSP430, for > example, SwiftX will go to sleep mode if no tasks are active, waking > when an interrupt signals something to do. > > Cheers, > Elizabeth I'll check out the MSP430 eval but I assume a CPU entering/exiting sleep mode won't facilitate the 'wake before STOP' scenario mentioned earlier?
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-10 09:11 +0100 |
| Message-ID | <ocfehb$467$1@dont-email.me> |
| In reply to | #56956 |
On 4/10/2017 01:37, Elizabeth D. Rather wrote: > > In many applications, there's nothing wrong with letting the multitasker > spin when nothing's going on, because in a PC, for example, it doesn't > cost any extra power. This is not true. Modern processors & PCs, and the OSes that run on them, support a number of sleep states to conserve power, and spinning on the spot disrupts them. > The cost is one machine instruction per task. > Typically putting a task to sleep is 3-4 machine instructions, and > waking the next one up maybe 5-6, so the whole thing is really pretty > efficient compared with conventional multitaskers. Again, this is not true, and there are many good reasons why this primitive technique isn't used. It is horribly inefficient of power; an Intel chip consumes several watts, up to hundreds, on full blast, and fractions of that while halted. It is cripplingly disruptive of other processes in the system, since the spinning task is consuming a scarce resource to no effective end. It is highly disruptive of the overall functioning of the system. Under Windows, the scheduler will keep lowering the priority of any task that does no more than burn CPU without returning to the OS now and again, as this kind of uncooperative behaviour has a serious impact on the responsiveness of other processes in the system. Even returning to the OS has serious downsides. You once advocated using KEY? in a loop as a technique. On Windows, KEY? is several 100s of thousands of instructions, and systems become rapidly unresponsive in the face of such a pointless battering. Exceptional circumstances aside, we're well beyond the effective use of spin waits now. Don't do it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-10 04:20 -0500 |
| Message-ID | <bIydnby3AqzK03bFnZ2dnUU7-VfNnZ2d@supernews.com> |
| In reply to | #56982 |
Alex <alex@rivadpm.com> wrote: > On 4/10/2017 01:37, Elizabeth D. Rather wrote: >> >> In many applications, there's nothing wrong with letting the multitasker >> spin when nothing's going on, because in a PC, for example, it doesn't >> cost any extra power. > > This is not true. Modern processors & PCs, and the OSes that run on > them, support a number of sleep states to conserve power, and spinning > on the spot disrupts them. Some of them do. >> The cost is one machine instruction per task. >> Typically putting a task to sleep is 3-4 machine instructions, and >> waking the next one up maybe 5-6, so the whole thing is really pretty >> efficient compared with conventional multitaskers. > > Again, this is not true, and there are many good reasons why this > primitive technique isn't used. It is horribly inefficient of power; > an Intel chip consumes several watts, up to hundreds, on full blast, > and fractions of that while halted. It is cripplingly disruptive of > other processes in the system, since the spinning task is consuming > a scarce resource to no effective end. It is highly disruptive of > the overall functioning of the system. You're not thinking about the full range of Forth systems. If you're running Forth under some other OS it makes sense to use its facilities appropriately, and in particular to use OS threads and system calls. If you're running Forth natively on an embedded system you might spin if there's nothing to do, or you might modify the multi-tasking loop to put the processor to sleep. It's not hard to do that, but there's no point if it's not needed. The world is not a PC. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-10 10:53 +0100 |
| Message-ID | <ocfkhb$8ig$1@dont-email.me> |
| In reply to | #56986 |
On 4/10/2017 10:20, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> On 4/10/2017 01:37, Elizabeth D. Rather wrote: >>> >>> In many applications, there's nothing wrong with letting the multitasker >>> spin when nothing's going on, because in a PC, for example, it doesn't >>> cost any extra power. >> >> This is not true. Modern processors & PCs, and the OSes that run on >> them, support a number of sleep states to conserve power, and spinning >> on the spot disrupts them. > > Some of them do. Some of them do what? > >>> The cost is one machine instruction per task. >>> Typically putting a task to sleep is 3-4 machine instructions, and >>> waking the next one up maybe 5-6, so the whole thing is really pretty >>> efficient compared with conventional multitaskers. >> >> Again, this is not true, and there are many good reasons why this >> primitive technique isn't used. It is horribly inefficient of power; >> an Intel chip consumes several watts, up to hundreds, on full blast, >> and fractions of that while halted. It is cripplingly disruptive of >> other processes in the system, since the spinning task is consuming >> a scarce resource to no effective end. It is highly disruptive of >> the overall functioning of the system. > > You're not thinking about the full range of Forth systems. If you're > running Forth under some other OS it makes sense to use its facilities > appropriately, and in particular to use OS threads and system calls. > If you're running Forth natively on an embedded system you might spin > if there's nothing to do, or you might modify the multi-tasking loop > to put the processor to sleep. It's not hard to do that, but there's > no point if it's not needed. The world is not a PC. The discussion here was about PCs & hosted Forths. If your chip supports Forth windmilling, go for it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-10 11:24 +0100 |
| Message-ID | <ocfmap$jf1$1@dont-email.me> |
| In reply to | #56988 |
On 4/10/2017 10:53, Alex wrote: > On 4/10/2017 10:20, Andrew Haley wrote: >> Alex <alex@rivadpm.com> wrote: >>> On 4/10/2017 01:37, Elizabeth D. Rather wrote: >>>> >>>> In many applications, there's nothing wrong with letting the >>>> multitasker >>>> spin when nothing's going on, because in a PC, for example, it doesn't >>>> cost any extra power. >>> >>> This is not true. Modern processors & PCs, and the OSes that run on >>> them, support a number of sleep states to conserve power, and spinning >>> on the spot disrupts them. >> >> Some of them do. > > Some of them do what? As a point of reference; https://software.intel.com/en-us/articles/long-duration-spin-wait-loops-on-hyper-threading-technology-enabled-intel-processors -- Alex
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web