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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-04-11 12:05 +1000 |
| Message-ID | <ochdnu$1r70$1@gioia.aioe.org> |
| In reply to | #56988 |
Alex wrote: > ... > The discussion here was about PCs & hosted Forths. Actually no. As the title suggests it's about the polyforth tasker and implementation strategies. Your contribution - which appears to be that round robins are crap - was the aside. In order to support the proposition you had to drag in examples of PC's and poor design.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-11 14:27 +0100 |
| Message-ID | <ocile6$7ro$1@dont-email.me> |
| In reply to | #57032 |
On 4/11/2017 03:05, HAA wrote: > Alex wrote: >> ... The discussion here was about PCs & hosted Forths. > > Actually no. As the title suggests it's about the polyforth tasker > and implementation strategies. Your contribution - which appears to > be that round robins are crap - was the aside. In order to support > the proposition you had to drag in examples of PC's and poor design. > I meant the direction that Elizabeth had taken it, which was explicitly about PCs. She said "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." It does cost power, and has other undesirable side effects too. As to round robins being crap, that's not what I said. It was about spin waits, which are not required by or unique to round robin scheduling, and what I said was; "Any technique that requires burning CPU while doing nothing is no more than a historical curiosity." I stand by it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-11 07:08 -0700 |
| Message-ID | <e11a25dd-5c4c-404e-bbfa-3ec67c7b1d08@googlegroups.com> |
| In reply to | #57044 |
Am Dienstag, 11. April 2017 15:27:28 UTC+2 schrieb Alex: > On 4/11/2017 03:05, HAA wrote: > > Alex wrote: > >> ... The discussion here was about PCs & hosted Forths. > > > > Actually no. As the title suggests it's about the polyforth tasker > > and implementation strategies. Your contribution - which appears to > > be that round robins are crap - was the aside. In order to support > > the proposition you had to drag in examples of PC's and poor design. > > > > I meant the direction that Elizabeth had taken it, which was explicitly > about PCs. She said "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." It does cost power, and > has other undesirable side effects too. > > As to round robins being crap, that's not what I said. It was about spin > waits, which are not required by or unique to round robin scheduling, > and what I said was; "Any technique that requires burning CPU while > doing nothing is no more than a historical curiosity." I stand by it. > > -- > Alex All this assumes that the Forth system IS the multi-tasking OS. This may happen in the "maker scene" or bare metal board development. Real world systems like industrial controllers already provide sometimes rather evolved task schedulers with different priority levels for interrupts and tasks, and various fixed cycle times for signal processing (e.g. every 100ms). Programming a round-robin or even polling loop in this context would be total nonsense.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-11 18:06 -0700 |
| Message-ID | <2ef60cba-5577-4813-ae93-3946cd4b415b@googlegroups.com> |
| In reply to | #57046 |
It would be nonsense until you hit a wall and throw it out and use a multi-tasking FORTH instead. Coop taskers combined with interrupts for non-deterministic inputs work very well in Forth where have complete control of when to switch. Typically you Pause on IO like Emit and inside the KEY loop so it's very smooth. I have built small databases in applications without formal record locking because I could control the record update routine to not yield until complete. It becomes so simple. Seems to have fallen out of favour. B
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-11 18:58 -0700 |
| Message-ID | <877f2ql73h.fsf@nightsong.com> |
| In reply to | #57082 |
foxaudioresearch@gmail.com writes: > I have built small databases in applications without formal record > locking because I could control the record update routine to not yield > until complete. It becomes so simple. Do you mean your db would lock up the system til disk i/o had completed? That doesn't sound so great. > Seems to have fallen out of favour. I don't know about falling out of favour (i.e. over time) but in more complicated systems, programmers seem to prefer pre-emptive multitasking, maybe because it's harder to hang the system through a single task locking up, things like your database don't stop the scheduler, etc. I've never used a cooperative tasker so don't know when the issues start appearing.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-12 13:57 -0700 |
| Message-ID | <f3ba41b0-66e3-4688-afed-8aebed8f9c49@googlegroups.com> |
| In reply to | #57085 |
On Tuesday, April 11, 2017 at 9:58:44 PM UTC-4, Paul Rubin wrote: > foxaudioresearch@gmail.com writes: > > I have built small databases in applications without formal record > > locking because I could control the record update routine to not yield > > until complete. It becomes so simple. > > Do you mean your db would lock up the system til disk i/o had completed? > That doesn't sound so great. > > > Seems to have fallen out of favour. > > I don't know about falling out of favour (i.e. over time) but in more > complicated systems, programmers seem to prefer pre-emptive > multitasking, maybe because it's harder to hang the system through a > single task locking up, things like your database don't stop the > scheduler, etc. I've never used a cooperative tasker so don't know when > the issues start appearing. The details would be determined by the application and the requirements. "Locking your database" is not accurate when it could be a single field write that is the protected if the application allows that. But that is the point of the coop tasker. You decide exactly when the slice happens not an arbitrary clock. On resource constrained systems it also means there is one less task... the scheduler itself! In the Forth cooperative model the scheduler is diffuse and spread through the I/O routines of the code. BF
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-12 18:02 -0700 |
| Message-ID | <8760i9jf0d.fsf@nightsong.com> |
| In reply to | #57175 |
foxaudioresearch@gmail.com writes: >> Do you mean your db would lock up the system til disk i/o had completed? > "Locking your database" is not accurate when it could be a single > field write that is the protected if the application allows that. I still don't understand this. You need to do some database operation that involves reading or updating the disk. Do you mean you wait for that to complete before your task yields? Or do you yield leaving the possibility of another task interfering? Or do you set some flag telling other tasks to not mess with the db until the current task is done with it? Such a flag is called a "lock" of course.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-12 19:47 -0700 |
| Message-ID | <91b82032-d469-47a8-8586-b7dfc4dc42ec@googlegroups.com> |
| In reply to | #57198 |
On Wednesday, April 12, 2017 at 9:02:59 PM UTC-4, Paul Rubin wrote: > foxaudioresearch@gmail.com writes: > >> Do you mean your db would lock up the system til disk i/o had completed? > > > "Locking your database" is not accurate when it could be a single > > field write that is the protected if the application allows that. > > I still don't understand this. You need to do some database operation > that involves reading or updating the disk. Do you mean you wait for > that to complete before your task yields? Or do you yield leaving the > possibility of another task interfering? Or do you set some flag > telling other tasks to not mess with the db until the current task is > done with it? Such a flag is called a "lock" of course. Yes it would wait for it to complete before the task yields, but you architect it in such a way that it is fast and no task waits very long... because you can. In my case I used the Forth Block word set for the raw disk access. The record storing word contained a word to yield only after all the fields were written into the buffer in RAM. In the coop tasker that meant that nobody else could write to that record for a short period of time. When it came time for Forth to flush the buffer out to disk it was writing to hard disk that locked the machine for the 1K write. My application was running on DOS so DOS did that 1K write to a file and it was fast enough. However if on an embedded system with it's own disk interface or flash you would have to make decisions on how much to write before yielding. But once you did that you would know it would be how you needed it rather than being interrupted by a timer in the middle of something important at a random time. The overall tasking switching in a traditional Forth tasker is actually handled by the I/O words. For example the Forth word emit in a multi-tasking system looks like: : EMIT (EMIT) PAUSE ; So you output a character and yield to the next task. Likewise KEY looks like: : KEY BEGIN PAUSE KEY? UNTIL KEYBUFFER C@ ; This creates a remarkable smooth task flow but it is critical that you have a fast context switch which happens to be pretty simple with Forth since you don't have to stack the entire register set. Just the SP, RP, IP and UP registers. It's actually a joy to work with. Very few surprises. BF
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-12 21:22 -0700 |
| Message-ID | <87r30xhr81.fsf@nightsong.com> |
| In reply to | #57203 |
foxaudioresearch@gmail.com writes: > When it came time for Forth to flush the buffer out to disk it was > writing to hard disk that locked the machine for the 1K write. My > application was running on DOS so DOS did that 1K write to a file and > it was fast enough. Oh ok, so the write was synchronous and you just relied on the hard disk being fast enough to not mess up the application too much. Maybe some tens of milliseconds on an old HDD. If that resulted in a usable system, then great. Of course with a floppy it would have been painful. The "proper" solution would have been for the task to only start the disk operation, and then an ISR would receive the notification wen the i/o was complete. So we're back to the issue of waking up a task from an ISR.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-04-13 02:57 -0700 |
| Message-ID | <0d703940-b6fc-44f8-b363-fcc5cfeb4dba@googlegroups.com> |
| In reply to | #57210 |
Proper is an interesting word. Using this coop mechanism polyforth could support over 10 terminals tied to a single IBM PC and was useful. Elizabeth could provide more insight than I can. I replicated some of polyforths functionality for my app on HSForth. B
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-12 23:17 -0700 |
| Message-ID | <46d8a45d-99b8-4f48-a011-f08d4de9e918@googlegroups.com> |
| In reply to | #57203 |
Am Donnerstag, 13. April 2017 04:47:59 UTC+2 schrieb foxaudio...@gmail.com: > : KEY BEGIN PAUSE KEY? UNTIL KEYBUFFER C@ ; Such loops cause the power drains (we discussed it): polling the round-robin chain. And it makes perhaps much more important tasks depend on a silly KEY?. KEY? might poll a slow serial terminal line... > It's actually a joy to work with. Very few surprises. Good. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-13 00:13 -0700 |
| Message-ID | <8737dcixu5.fsf@nightsong.com> |
| In reply to | #57213 |
minforth@arcor.de writes: >> : KEY BEGIN PAUSE KEY? UNTIL KEYBUFFER C@ ; > Such loops cause the power drains (we discussed it) : KEY BEGIN PAUSE 10 MS KEY? UNTIL KEYBUFFER C@ ; might be enough to fix that.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-13 09:43 -1000 |
| Message-ID | <CpWdna89psBySXLFnZ2dnUU7-N2dnZ2d@supernews.com> |
| In reply to | #57217 |
On 4/12/17 9:13 PM, Paul Rubin wrote: > minforth@arcor.de writes: >>> : KEY BEGIN PAUSE KEY? UNTIL KEYBUFFER C@ ; >> Such loops cause the power drains (we discussed it) > > : KEY BEGIN PAUSE 10 MS KEY? UNTIL KEYBUFFER C@ ; > > might be enough to fix that. No, because the task is still polling the MS clock. If you want to save CPU clocks, you really want to use interrupts. 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-13 19:34 -0700 |
| Message-ID | <87vaq7hg4l.fsf@nightsong.com> |
| In reply to | #57257 |
"Elizabeth D. Rather" <erather@forth.com> writes: > No, because the task is still polling the MS clock. If you want to > save CPU clocks, you really want to use interrupts. Wait, what? The MS clock is a busy loop? OK but that never would have occurred to me. Yikes.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-13 19:57 -1000 |
| Message-ID | <mqGdnYQe2bgs-W3FnZ2dnUU7-IXNnZ2d@supernews.com> |
| In reply to | #57268 |
On 4/13/17 4:34 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> No, because the task is still polling the MS clock. If you want to >> save CPU clocks, you really want to use interrupts. > > Wait, what? The MS clock is a busy loop? OK but that never would have > occurred to me. Yikes. > It's an implementation thing. On some systems the clock is implemented with an interrupt that tallies a counter. MS has to look at the counter, subtract, and see if the requested number of milliseconds has elapsed. It's nice if the hardware will sleep and wake you up in n milliseconds, but then what if multiple tasks are waiting on different intervals? That gets complicated. If someone is keeping track, that takes cycles. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-14 02:45 -0400 |
| Message-ID | <ocpr1b$p4b$1@dont-email.me> |
| In reply to | #57273 |
On 4/14/2017 1:57 AM, Elizabeth D. Rather wrote: > On 4/13/17 4:34 PM, Paul Rubin wrote: >> "Elizabeth D. Rather" <erather@forth.com> writes: >>> No, because the task is still polling the MS clock. If you want to >>> save CPU clocks, you really want to use interrupts. >> >> Wait, what? The MS clock is a busy loop? OK but that never would have >> occurred to me. Yikes. >> > > It's an implementation thing. On some systems the clock is implemented > with an interrupt that tallies a counter. MS has to look at the counter, > subtract, and see if the requested number of milliseconds has elapsed. > It's nice if the hardware will sleep and wake you up in n milliseconds, > but then what if multiple tasks are waiting on different intervals? That > gets complicated. If someone is keeping track, that takes cycles. Complicated? It requires a simple ordered list (or a non-ordered list that is searched) of wake up times, one for each task that is sleeping. When all processes are asking to sleep the wake up timer is set for the next wake up event. That's complicated? I bet Hugh could code that in his sleep (pun intended)! ;) -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-04-13 21:28 -1000 |
| Message-ID | <6_ydnXUzTNeS523FnZ2dnUU7-THNnZ2d@supernews.com> |
| In reply to | #57275 |
On 4/13/17 8:45 PM, rickman wrote: > On 4/14/2017 1:57 AM, Elizabeth D. Rather wrote: >> On 4/13/17 4:34 PM, Paul Rubin wrote: >>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>> No, because the task is still polling the MS clock. If you want to >>>> save CPU clocks, you really want to use interrupts. >>> >>> Wait, what? The MS clock is a busy loop? OK but that never would have >>> occurred to me. Yikes. >>> >> >> It's an implementation thing. On some systems the clock is implemented >> with an interrupt that tallies a counter. MS has to look at the counter, >> subtract, and see if the requested number of milliseconds has elapsed. >> It's nice if the hardware will sleep and wake you up in n milliseconds, >> but then what if multiple tasks are waiting on different intervals? That >> gets complicated. If someone is keeping track, that takes cycles. > > Complicated? It requires a simple ordered list (or a non-ordered list > that is searched) of wake up times, one for each task that is sleeping. > When all processes are asking to sleep the wake up timer is set for the > next wake up event. > > That's complicated? I bet Hugh could code that in his sleep (pun > intended)! ;) In fact, it's far less complicated than that. Each task knows how long it's sleeping, and each time around the round-robin checks to see if it's wake-up time yet. A very few instructions each time. Cheers, Elizabeth -- Elizabeth D. Rather FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-14 07:53 +0000 |
| Message-ID | <2017Apr14.095322@mips.complang.tuwien.ac.at> |
| In reply to | #57276 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>In fact, it's far less complicated than that. Each task knows how long
>it's sleeping, and each time around the round-robin checks to see if it's
>wake-up time yet. A very few instructions each time.
If you have 100 tasks waiting in MS, that's maybe 1000 instructions
and 100 cache line touches (20% of the L1 cache of a recent Intel CPU)
every time a working task PAUSEs. And if you have 1000 such tasks,
every PAUSE scrubs the L1 cache and causes 1000 L1 cache misses (i.e.,
about 50000 cycles from the cache misses alone). It's simple, but it
does not scale.
And it burns CPU when everything is waiting.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-14 01:44 -0700 |
| Message-ID | <87mvbjgyyl.fsf@nightsong.com> |
| In reply to | #57277 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > And if you have 1000 such tasks, every PAUSE scrubs the L1 cache... > It's simple, but it does not scale. Tbh I don't imagine using this tasking scheme on a big x86 with 1000s of tasks. But a small embedded program might still use a few tens of tasks. Maybe the scheme can work at that level. I came across a really nice little board, a new addition to the Adafruit Feather series: https://www.adafruit.com/product/3403 - 48 mhz ARM Cortex M0 cpu, 256k on-chip flash, 32k on-chip ram - 32 khz on-board crystal for use with built-in RTC counter in the cpu - 2MB on-board SPI flash, with boot loader that makes the whole board look like a USB mass storage device, so you can drag and drop files to it from your PC - Max power drain seems to be around 6 mA when running benchmark code. Usually much less than that. - Can be powered from USB port or Lipo cell through JST connector. Automatically charges Lipo cell from USB power. - Lots of analog and digital i/o pins, Feather add-on boards, etc. - Costs 20 USD, a bit steep by AliExpress standards but not bad unless you need a lot of them. It's made to run a MicroPython fork but it seems to call for a completely self-hosted Forth system with multitasking.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-14 02:01 -0700 |
| Message-ID | <01a24826-476b-42e2-b919-d0d9a8011b66@googlegroups.com> |
| In reply to | #57279 |
Am Freitag, 14. April 2017 10:44:51 UTC+2 schrieb Paul Rubin: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > > And if you have 1000 such tasks, every PAUSE scrubs the L1 cache... > > It's simple, but it does not scale. > > Tbh I don't imagine using this tasking scheme on a big x86 with 1000s of > tasks. But a small embedded program might still use a few tens of > tasks. Maybe the scheme can work at that level. > > I came across a really nice little board, a new addition to the Adafruit > Feather series: > > https://www.adafruit.com/product/3403 > > - 48 mhz ARM Cortex M0 cpu, 256k on-chip flash, 32k on-chip ram > - 32 khz on-board crystal for use with built-in RTC counter in the cpu > - 2MB on-board SPI flash, with boot loader that makes the whole board > look like a USB mass storage device, so you can drag and drop files > to it from your PC > - Max power drain seems to be around 6 mA when running benchmark code. > Usually much less than that. > - Can be powered from USB port or Lipo cell through JST connector. > Automatically charges Lipo cell from USB power. > - Lots of analog and digital i/o pins, Feather add-on boards, etc. > - Costs 20 USD, a bit steep by AliExpress standards but not bad > unless you need a lot of them. > > It's made to run a MicroPython fork but it seems to call for a > completely self-hosted Forth system with multitasking. 6 mA at 3 V makes 18 mW peak. I don't know much about such boards, but I'd expect power ratings below 1 mW for such tiny things today.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web