IDLE-EKEY? 
Author Message
 IDLE-EKEY?

A loop that calls EKEY? (or KEY? ) is a really stupid thing on
some platforms.

Why don't we have two versions of EKEY? : one called in the
middle of a process that must not get delayed, and the other
called from within an idle loop.

For simple on-board systems, : IDLE-EKEY? EKEY? ;
For Win32 it may be, say, : IDLE-EKEY? EKEY? DUP 0= IF 100 MS THEN ;

The difference is that IDLE-EKEY? is allowed to give control
to other threads/processes in the system.
After n-th invocation it may return control only when
some keyboard event is indeed available.

A sort of compromise between portability and suitability on modern OSes.

What do you think about this idea?



Mon, 15 Nov 2004 18:08:29 GMT  
 IDLE-EKEY?

Quote:

> The difference is that IDLE-EKEY? is allowed to give control
> to other threads/processes in the system.
> After n-th invocation it may return control only when
> some keyboard event is indeed available.

> A sort of compromise between portability and suitability on modern OSes.

> What do you think about this idea?

PAUSE is often used to donate CPU time back to the task switcher.
Thus, your IDLE-EKEY would be defined as this:

: IDLE-EKEY?   PAUSE EKEY? ;

I do not recall if PAUSE is ANSI standard, but it is very commonly
used.

However, it is the purpose of EKEY (note the lack of ?) to put the
Forth process on hold while waiting for some external event to arrive.
 It literally is Forth's version of XNextEvent(), or WaitMessage(), or
even AmigaOS's Wait() call.

I am intimately aware of AmigaOS's interprocess communications
methods, so I'll use that as an example.  In AmigaOS, Wait() is,
ultimately, the only kernel function that can put a task to sleep.  It
takes as a parameter a mask, indicating which subset of events to wait
for.  The task is responsible for mapping events to these "signal
bits" (not to be confused with Unix signals!  Think VMS event bits
instead) at some point before invoking Wait().  That's an
implementation detail and is not important to the discussion.

A typical event-loop (for a hypothetical terminal program) in AmigaOS
looks like this (in C):

  done = FALSE;
  while( !done )
  {
    events = Wait( WindowEventMask | SerialIOMask | TimerEventMask );
    if( events & WindowEventMask )
      done = HandleWindowEvents();
    if( events & SerialIOMask )  /* NOTE LACK OF else!! */
      done |= HandleSerialIO();
    if( events & TimerEventMask )
      done |= HandleTimer();
  }

In Forth, EKEY does not take parameters, so it would map to Wait(
0xFFFFFFFF ) in AmigaOS (wait for anything to occur).  The result of
EKEY would be the result of Wait().

: HandleWindowEvents ( -- done? )   ... ;
: HandleSerialIO ( -- done? )       ... ;
: HandleTimer ( -- done? )          ... ;

: HandleEvents ( mask -- mask' )
  FALSE



: MainLoop
  BEGIN EKEY HandleEvents ( done? ) UNTIL ;

In AmigaOS, a single signal bit can correspond to any number of input
events (a single AmigaOS task/thread is not restricted to a single
message queue; likewise, if you were really {*filter*}ic, multiple
threads could draw events from a single queue).  Thus, something like
EKEY>KEY will not work, at least not with the solution I've provided
above, unless the Forth environment provides better emulation for the
ANSI Forth I/O model.  Regardless of whether it does or does not, it
is ultimately EKEY's job to relieve the Forth program of CPU time,
while waiting for an event (KEY is defined in terms of EKEY, at least
conceptually; : KEY EKEY EKEY>KEY ;).

Which brings us back to PAUSE; PAUSE differs from EKEY in that it does
not return anything; as far as the Forth program is concerned, it's a
no-operation word that does nothing.  The reality of its purpose,
however, is to donate CPU time back to the operating system so it can
perform other tasks.  This is more important on cooperative
multitasking systems than on preemptive multitasking systems, but even
on the latter it can find some uses.

--
Samuel A. Falvo II



Wed, 17 Nov 2004 04:08:31 GMT  
 IDLE-EKEY?

Quote:

> > The difference is that IDLE-EKEY? is allowed to give control
> > to other threads/processes in the system.
> > After n-th invocation it may return control only when
> > some keyboard event is indeed available.

> > A sort of compromise between portability and suitability on modern OSes.

> > What do you think about this idea?

> PAUSE is often used to donate CPU time back to the task switcher.
> Thus, your IDLE-EKEY would be defined as this:

> : IDLE-EKEY?   PAUSE EKEY? ;

> I do not recall if PAUSE is ANSI standard, but it is very commonly
> used.

It is not standard, but it is certainly common practice.

Quote:
> However, it is the purpose of EKEY (note the lack of ?) to put the
> Forth process on hold while waiting for some external event to arrive.
>  It literally is Forth's version of XNextEvent(), or WaitMessage(), or
> even AmigaOS's Wait() call.

It has always been our practice to include a PAUSE or equivalent in
_any_ word that does I/O, whether it waits (like KEY or EKEY) or
just queries (like KEY? or EKEY?).  This is the magic that makes a
simple cooperative multitasker work pretty much effortlessly, because
there are relatively few places where you do a lot of work w/ no
I/O of any kind.  And those few can be fixed with a few explicit
PAUSEs in strategic places.

Cheers,
Elizabeth



Wed, 17 Nov 2004 05:28:27 GMT  
 IDLE-EKEY?

Quote:
> It has always been our practice to include a PAUSE or equivalent in
> _any_ word that does I/O, whether it waits (like KEY or EKEY) or
> just queries (like KEY? or EKEY?).  This is the magic that makes a
> simple cooperative multitasker work pretty much effortlessly, because

Certainly.

Quote:
> there are relatively few places where you do a lot of work w/ no
> I/O of any kind.  And those few can be fixed with a few explicit
> PAUSEs in strategic places.

I prefer preemptive multitasking since it centralizes the location of
PAUSE, and frees me from ever having to worry about it.  Some people
argue that it complicates the design of a system, but I find the
reverse is true.  When writing Dolphin 0.2, my first kernel to employ
preemptive multitasking, I implemented first cooperative multitasking,
and then I inserted the equivalent to PAUSE in the timer interrupt
handler.  Voila -- instant preemption.

The nice thing about using PAUSE manually is that you can implement a
multitasking Forth environment on an inherently non-multitasking
operating system like CP/M or DOS.  But you have to be pretty
disciplined in your use of PAUSE; one mistake can effectively freeze
the system solid, depending on what the task is doing.  :)

--
Samuel A. Falvo II



Fri, 19 Nov 2004 12:56:05 GMT  
 IDLE-EKEY?

Quote:
> The nice thing about using PAUSE manually is that you can implement a
> multitasking Forth environment on an inherently non-multitasking
> operating system like CP/M or DOS.  But you have to be pretty
> disciplined in your use of PAUSE; one mistake can effectively freeze
> the system solid, depending on what the task is doing.  :)

Having used the scheme I described (all I/O implicitly PAUSEs, and
you can also insert PAUSEs manually to tune a CPU-intensive
operation) for nearly 30 years in a vast array of applications, I
must say we've found it to be extremely robust, easy to use and
low-overhead.  It's been successful on DOS and in purely
native environments (e.g. embedded systems), although we
use a different algorithm under Windows.

The charms of non-preeemptive multitasking include the fact
that a context switch is extremely fast (typically saving and
restoring 2 registers and setting a 3rd, ~10 machine instructions
or less on most CPUs), and the programmer has the
benefit that you know when context switches will occur and
when you can be sure they will not.

Cheers,
Elizabeth



Fri, 19 Nov 2004 22:22:51 GMT  
 IDLE-EKEY?

Quote:

>> It has always been our practice to include a PAUSE or equivalent in
>> _any_ word that does I/O, whether it waits (like KEY or EKEY) or
>> just queries (like KEY? or EKEY?).  This is the magic that makes a
>> simple cooperative multitasker work pretty much effortlessly, because
> Certainly.
>> there are relatively few places where you do a lot of work w/ no
>> I/O of any kind.  And those few can be fixed with a few explicit
>> PAUSEs in strategic places.
> I prefer preemptive multitasking since it centralizes the location of
> PAUSE, and frees me from ever having to worry about it.

If every thread in an application can be pre-empted at any time you
have to worry a great deal about access to shared storage and
peripherals.  Semaphores and mutexes are necessary, and deadlock is a
potential problem.  In a co-operative system, interlocks are usually
unnecessary.

On the other hand, the need to insert explicit PAUSEs in a
co-operative system is in my experience very rare.  Many complex
applications contain no explicit PAUSEs at all -- implicit PAUSEs in
I/O are quite sufficient.

Andrew.



Sat, 20 Nov 2004 02:07:58 GMT  
 IDLE-EKEY?

Quote:


> > The nice thing about using PAUSE manually is that you can implement a
> > multitasking Forth environment on an inherently non-multitasking
> > operating system like CP/M or DOS.  But you have to be pretty
> > disciplined in your use of PAUSE; one mistake can effectively freeze
> > the system solid, depending on what the task is doing.  :)

> Having used the scheme I described (all I/O implicitly PAUSEs, and
> you can also insert PAUSEs manually to tune a CPU-intensive
> operation) for nearly 30 years in a vast array of applications, I
> must say we've found it to be extremely robust, easy to use and
> low-overhead.  It's been successful on DOS and in purely
> native environments (e.g. embedded systems), although we
> use a different algorithm under Windows.

What do you use under Windows?

- Show quoted text -

Quote:

> The charms of non-preeemptive multitasking include the fact
> that a context switch is extremely fast (typically saving and
> restoring 2 registers and setting a 3rd, ~10 machine instructions
> or less on most CPUs), and the programmer has the
> benefit that you know when context switches will occur and
> when you can be sure they will not.

> Cheers,
> Elizabeth



Sat, 20 Nov 2004 02:26:48 GMT  
 IDLE-EKEY?

Quote:

> > Having used the scheme I described (all I/O implicitly PAUSEs, and
> > you can also insert PAUSEs manually to tune a CPU-intensive
> > operation) for nearly 30 years in a vast array of applications, I
> > must say we've found it to be extremely robust, easy to use and
> > low-overhead.  It's been successful on DOS and in purely
> > native environments (e.g. embedded systems), although we
> > use a different algorithm under Windows.

> What do you use under Windows?

Windows-type processes and threads.  It's really the only way
to get concurrency without violating the rules of "good
citizenship" in the Windows environment.  It's described at
length in the SwiftForth Reference Manual (distributed as pdf
with all SwiftForths).

Cheers,
Elizabeth



Sat, 20 Nov 2004 05:10:35 GMT  
 IDLE-EKEY?

Quote:

> If every thread in an application can be pre-empted at any time you
> have to worry a great deal about access to shared storage and
> peripherals.  Semaphores and mutexes are necessary, and deadlock is a
> potential problem.  In a co-operative system, interlocks are usually
> unnecessary.

I've been programming preemptive multitasking systems since the Amiga
first hit the market in 1985.  I can't really say that I've ever had
any problems at all writing for preemptive environments.

OTOH, I have also written code for cooperative environments, and I've
been nothing but utterly unhappy with the performance of them.  Now,
admittedly, none of these environments have been Forth environments.
However, I also admit to **NEVER** having any need for cooperative
multitasking in Forth.  If it can be expressed using cooperative
multitasking in Forth, it usually can be expressed in an equivalent
program without it.  The same is not true for preemptive environments.

Quote:
> On the other hand, the need to insert explicit PAUSEs in a
> co-operative system is in my experience very rare.  Many complex
> applications contain no explicit PAUSEs at all -- implicit PAUSEs in
> I/O are quite sufficient.

Where are you getting the idea that I think you need explicit PAUSEs
in application code?  Certainly for compute-intensive applications,
but the majority of the code is I/O bound anyway.  I will not refute
this.

However, the disadvantage to this is when you end up in an infinite
loop in your Forth code.  This is not as uncommon as you might think,
considering many Forth environments are either unprotected (no memory
protection), or simple programmer error guarantees that a WHILE
condition is always satisfied.  Under an environment where the Forth
system runs hosted (e.g., under Linux or Windows, for example), this
isn't a problem -- just kill the Forth environment, restart, and off
you go.  But what if the Forth environment runs native.  What are you
going to do, reboot?  In many systems, that is not an option.

A preemptive environment, on the other hand, always guarantees that
I/O peripherals can respond to their interrupts, which if necessary,
may include killing the currently running process (e.g., user types
CTRL-C for example).  Interrupt handlers would signal a suitably high
priority task, causing a reschedule to run that task when all
interrupt handlers are done doing whatever it is they do.  It's no
more complicated than a cooperative system in actual implementation.

Yes, you now have to worry about concurrent access to shared
variables.  But the reality is that even that isn't the problem most
people make it out to be.  The utter lack of suitable interprocess
communications facilities in popular operating systems like Windows
and Unix exacerbates the problem significantly; AmigaOS and VMS, on
the other hand, make such matters quite trivial.  AmigaOS in
particular employs message passing for nearly **ALL** of its
interprocess communications needs; heck, they didn't get semaphores
until Kickstart 1.2, the third iteration of the operating system!
Even today, AmigaOS 4.0 still only has message passing (which relies
on signals) and semaphores for IPC.

Deadlock is also a problem in cooperative environments as well.  I've
run into situations where two processes need access to a shared
resource, and a third process, which has already used the resource in
question, has not suitably released the resource for use in the
remainder of the system.  The result?  Two processes are now
deadlocked, and the third will deadlock the next time it goes to
re-acquire the resource.

You make it sound like preemption is somehow evil and unnecessary.  If
that were the case, we'd still be using Windows 3.1 and MacOS System
7.  Before you use the argument that nearly all Forth environments are
quite happy with cooperative multitasking, I'd also like to point out
that nearly all of those Forth environments run hosted under
environments where preemption is difficult to implement from within
the Forth environment itself.  For example, it's very difficult to
implement preemptive multitasking under DOS, for DOS and BIOS
themselves are not preemptable.  However, under Win32, as Elizabeth
pointed out, preemptive multitasking is employed.  "It's the only way
to play by the rules," I believe she wrote.  The same would be true
under Linux as well -- it'd be a foolish waste to employ cooperative
multitasking in Forth programs under Linux.

Cooperative multitasking is, ultimately, not an optimal solution
UNLESS YOU ARE IN FULL CONTROL OF THE WHOLE SYSTEM, and you, as a
programmer, can guarantee response times to I/O stimuli.  Most Forth
environments grant you that control, as it's being used in embedded
devices.  But for desktop class applications, cooperative multitasking
has been proven useless.

--
Samuel A. Falvo II



Sun, 21 Nov 2004 06:19:47 GMT  
 IDLE-EKEY?

Quote:

>> If every thread in an application can be pre-empted at any time you
>> have to worry a great deal about access to shared storage and
>> peripherals.  Semaphores and mutexes are necessary, and deadlock is a
>> potential problem.  In a co-operative system, interlocks are usually
>> unnecessary.
> I've been programming preemptive multitasking systems since the Amiga
> first hit the market in 1985.  I can't really say that I've ever had
> any problems at all writing for preemptive environments.
> OTOH, I have also written code for cooperative environments, and I've
> been nothing but utterly unhappy with the performance of them.  Now,
> admittedly, none of these environments have been Forth environments.

Well, I was talking about Forth-based operating systems; none of my
comments applied to anything else.  BTW, it's quite common for people
to disbelieve that co-operative Forth multitasking can work well.

Quote:
>> On the other hand, the need to insert explicit PAUSEs in a
>> co-operative system is in my experience very rare.  Many complex
>> applications contain no explicit PAUSEs at all -- implicit PAUSEs in
>> I/O are quite sufficient.
> Where are you getting the idea that I think you need explicit PAUSEs
> in application code?  Certainly for compute-intensive applications,
> but the majority of the code is I/O bound anyway.  I will not refute
> this.

Right.

Quote:
> However, the disadvantage to this is when you end up in an infinite
> loop in your Forth code.  This is not as uncommon as you might think,
> considering many Forth environments are either unprotected (no memory
> protection), or simple programmer error guarantees that a WHILE
> condition is always satisfied.  Under an environment where the Forth
> system runs hosted (e.g., under Linux or Windows, for example), this
> isn't a problem -- just kill the Forth environment, restart, and off
> you go.  But what if the Forth environment runs native.  What are you
> going to do, reboot?

The usual thing is to have watchdog timers and/or a supervisory task
that ensures the whole system is running correctly.  If it's not, the
supervisor will either restart individual tasks or, in extremis, restart
the whole system.

Quote:
> A preemptive environment, on the other hand, always guarantees that
> I/O peripherals can respond to their interrupts, which if necessary,
> may include killing the currently running process (e.g., user types
> CTRL-C for example).

Of course, there's no need to forbid interrupt-driven I/O in a
co-operative Forth system: in practice interrupts are essential.

Quote:
> Interrupt handlers would signal a suitably high priority task,
> causing a reschedule to run that task when all interrupt handlers
> are done doing whatever it is they do.  It's no more complicated
> than a cooperative system in actual implementation.

There we must agree to differ.

Quote:
> Yes, you now have to worry about concurrent access to shared
> variables.  But the reality is that even that isn't the problem most
> people make it out to be.  The utter lack of suitable interprocess
> communications facilities in popular operating systems like Windows
> and Unix exacerbates the problem significantly; AmigaOS and VMS, on
> the other hand, make such matters quite trivial.  AmigaOS in
> particular employs message passing for nearly **ALL** of its
> interprocess communications needs; heck, they didn't get semaphores
> until Kickstart 1.2, the third iteration of the operating system!
> Even today, AmigaOS 4.0 still only has message passing (which relies
> on signals) and semaphores for IPC.
> Deadlock is also a problem in cooperative environments as well.  I've
> run into situations where two processes need access to a shared
> resource, and a third process, which has already used the resource in
> question, has not suitably released the resource for use in the
> remainder of the system.

But in most cases in a co-operative system you don't need to lock
resources at all, so this is far less likely to occur.

Quote:
> The result?  Two processes are now deadlocked, and the third will
> deadlock the next time it goes to re-acquire the resource.
> You make it sound like preemption is somehow evil and unnecessary.

No, not at all.  I'm saying that in the context of a Forth system
pre-emption is unlikely to reduce the cost or increase the performance
of an application.

Quote:
> If that were the case, we'd still be using Windows 3.1 and MacOS
> System 7.  Before you use the argument that nearly all Forth
> environments are quite happy with cooperative multitasking, I'd also
> like to point out that nearly all of those Forth environments run
> hosted under environments where preemption is difficult to implement
> from within the Forth environment itself.  For example, it's very
> difficult to implement preemptive multitasking under DOS, for DOS
> and BIOS themselves are not preemptable.  However, under Win32, as
> Elizabeth pointed out, preemptive multitasking is employed.  "It's
> the only way to play by the rules," I believe she wrote.

Of course; it you're working in a particular system you must play by
the rules.

Quote:
> The same would be true under Linux as well

I don't think that's true at all, as Linux asynchronous I/O permits
applications to have many outstanding I/O requests and continue
processing.

Quote:
> -- it'd be a foolish waste to employ cooperative multitasking in
> Forth programs under Linux.

I suspect that it depends on the application.  If you wanted a
super-lightweight thread, the use of a clone-based Linux thread my be
prohibitive.

Quote:
> Cooperative multitasking is, ultimately, not an optimal solution
> UNLESS YOU ARE IN FULL CONTROL OF THE WHOLE SYSTEM, and you, as a
> programmer, can guarantee response times to I/O stimuli.  Most Forth
> environments grant you that control, as it's being used in embedded
> devices.

That doesn't seem to make sense: if you're working in a non-realtime
environment you can't guarantee response times in any case.

Quote:
> But for desktop class applications, cooperative multitasking
> has been proven useless.

Andrew.


Sun, 21 Nov 2004 16:32:53 GMT  
 IDLE-EKEY?

Quote:

> The usual thing is to have watchdog timers and/or a supervisory task
> that ensures the whole system is running correctly.  If it's not, the

But this is strongly leaning towards a preemptive system now.  OK,
maybe it doesn't have timeslicing (preemption and timeslicing are not
the same thing, though they're often used together.  MMURTL, for
example, demonstrates a prioritized, preemptive multitasking system
that does NOT timeslice, relying on cooperation between tasks of equal
priority).

Quote:
> Of course, there's no need to forbid interrupt-driven I/O in a
> co-operative Forth system: in practice interrupts are essential.

What I was getting at was placing the bulk of a device driver in an
ISR, which is common in non-preemptive environments.  Many protected
operating system environments seriously limit what can be done in ISR
code, to ensure proper operation of the kernel and response times for
all tasks.

Quote:
> > are done doing whatever it is they do.  It's no more complicated
> > than a cooperative system in actual implementation.

> There we must agree to differ.

I've written four multitasking kernels already which utilize
preemption and timeslicing.  You can differ all you want.  My
experience shows otherwise.

Quote:
> But in most cases in a co-operative system you don't need to lock
> resources at all, so this is far less likely to occur.

So you're saying every task in the system has free reign over the
serial port?  Over the network card?  Over low-level disk
functionality?  Over the PCI bus enumerator?  Over the motherboard
timer?

The reality of the situation is, in cooperative environments, you need
resource locking every bit as much as you do under a preemptive
environment.

Quote:
> Of course; it you're working in a particular system you must play by
> the rules.

Or if you are creating your own system, as I currently am, you can set
the rules.  If you prefer cooperative multitasking, go for it.
Personally, I prefer preemptive.  :)

Quote:
> I don't think that's true at all, as Linux asynchronous I/O permits
> applications to have many outstanding I/O requests and continue
> processing.

Quite true, and I bring this up with my EKEY discussion, where EKEY
would basically call upon select() or poll() (interestingly enough,
poll() doesn't actually poll!), Unix's version of AmigaOS's Wait()
function.  When data arrives, it would wrap the appropriate event into
a structure, and pass its address back as the result of EKEY.

But now we're getting into implementation issues.

Quote:
> I suspect that it depends on the application.  If you wanted a
> super-lightweight thread, the use of a clone-based Linux thread my be
> prohibitive.

The limitation to this would be the number of outstanding I/O channels
(file descriptors, basically) you can poll with select() or poll().
IIRC, Linux only allows 32 file descriptors (can anyone deny this?
I'm definately interested in hearing about it in more detail) to be
used with these functions.  Hence, if you were to associate one
cooperative thread per network connection (for example), you're
limited to only 31 threads.  They may sound like a lot, but when
writing software to be deployed in a corporate environment, or an
online {*filter*} environment, that can be just as prohibitive.

Quote:
> That doesn't seem to make sense: if you're working in a non-realtime
> environment you can't guarantee response times in any case.

I think you're making the mistake of associating preemption with
non-realtime response.  QNX demonstrates this isn't the case, as does
many other hard real time operating systems.  I'm not aware of a
single cooperative multitasking environment (except those written in
Forth where application and OS are indistinguishable) that has
successfully been employed in a hard real time environment.

--
Samuel A. Falvo II



Mon, 22 Nov 2004 07:06:28 GMT  
 IDLE-EKEY?

Quote:


> > The usual thing is to have watchdog timers and/or a supervisory task
> > that ensures the whole system is running correctly.  If it's not, the

> But this is strongly leaning towards a preemptive system now.  OK,
> maybe it doesn't have timeslicing (preemption and timeslicing are not
> the same thing, though they're often used together.  MMURTL, for
> example, demonstrates a prioritized, preemptive multitasking system
> that does NOT timeslice, relying on cooperation between tasks of equal
> priority).

If you have an infinite loop, what you really have is an inadequately
tested system which shouldn't be released in a production environment.

Quote:
> > Of course, there's no need to forbid interrupt-driven I/O in a
> > co-operative Forth system: in practice interrupts are essential.

> What I was getting at was placing the bulk of a device driver in an
> ISR, which is common in non-preemptive environments.  Many protected
> operating system environments seriously limit what can be done in ISR
> code, to ensure proper operation of the kernel and response times for
> all tasks.

Our multitaskers (currently SwiftOS in SwiftX, formerly pF/x in
polyFORTH on much the same model) don't place any such limitations,
but we do offer advice, which is that the ISR should do only a bare
minimum of time-critical servicing (e.g. read a key or a value on an
A/D an put it somewhere) and let the task responsible for
the device handle the rest of the logic when it wakes up on
its next turn (usually within microseconds).

Quote:
> > > are done doing whatever it is they do.  It's no more complicated
> > > than a cooperative system in actual implementation.

> > There we must agree to differ.

> I've written four multitasking kernels already which utilize
> preemption and timeslicing.  You can differ all you want.  My
> experience shows otherwise.

But you said you hadn't used a Forth multitasker of the type
I'm describing, so you lack at least that experience.  I can
certainly see that if you've always used preemption and time
slicing that's what you'd feel most comfortable with, but you
might be surprised...

Quote:
> > But in most cases in a co-operative system you don't need to lock
> > resources at all, so this is far less likely to occur.

> So you're saying every task in the system has free reign over the
> serial port?  Over the network card?  Over low-level disk
> functionality?  Over the PCI bus enumerator?  Over the motherboard
> timer?

Our multitasker is normally used in a dedicated, native environment
where we don't have to worry about arbitrary task behaviors.  Design
of the application normally assigns responsibility for certain
devices to certain tasks, but may make arrangements for sharing.
For example, we've had systems with literally hundreds of tasks
sharing the disk.  We do have a simple semaphore to manage such
situations, but interlocks are extremely rare (and even then caught
in the testing phase).

Quote:
>...
> I think you're making the mistake of associating preemption with
> non-realtime response.  QNX demonstrates this isn't the case, as does
> many other hard real time operating systems.  I'm not aware of a
> single cooperative multitasking environment (except those written in
> Forth where application and OS are indistinguishable) that has
> successfully been employed in a hard real time environment.

Probably true, a good rationale for using Forth in such projects :-)

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

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



Mon, 22 Nov 2004 07:53:25 GMT  
 IDLE-EKEY?

Quote:

>> But in most cases in a co-operative system you don't need to lock
>> resources at all, so this is far less likely to occur.
> So you're saying every task in the system has free reign over the
> serial port?  Over the network card?  Over low-level disk
> functionality?  Over the PCI bus enumerator?  Over the motherboard
> timer?

In practice, it's easier to allow a task to "own" a serial port and
route requests through that task.  With regard to other physical
resources -- timers and so on -- it's sometimes necessary to lock,
yes.

Quote:
> The reality of the situation is, in cooperative environments, you need
> resource locking every bit as much as you do under a preemptive
> environment.

Not every bit as much, since you don't need to lock something if you
know that a task switch cannot occur while you're accessing it.

My argument is simply that pre-emptive systems have both advantages
and disadvantages: which is best depends on the application.

Andrew.



Tue, 23 Nov 2004 00:09:35 GMT  
 IDLE-EKEY?

Quote:
> If you have an infinite loop, what you really have is an inadequately
> tested system which shouldn't be released in a production environment.

I *KNEW* this argument would come up sooner or later, and how often it
is relied upon instead of addressing the problem for what it is.

I am currently working with hardware with a non-multitasking system of
any kind right now.  And occasionally, being the imperfect human that
I am, I end up creating an inadvertent infinite loop.  Rebooting the
computer to fix the problem is a very lengthy, costly solution to what
would be a *TRIVIAL* problem in a pre-emptively multitasking
environment.

It's especially important when the system in question is open-ended.
If you cannot control what software the user will use in conjunction
with your own, you therefore cannot control the security of the system
as a whole.  No matter how bug-free *YOUR* code is, if my code hangs
the system, your code fails (to the user, it doesn't matter who's
fault it is -- all he or she knows is the system is hung solid, and
(s)he will be right miffed!).

Quote:
> But you said you hadn't used a Forth multitasker of the type
> I'm describing, so you lack at least that experience.  I can
> certainly see that if you've always used preemption and time
> slicing that's what you'd feel most comfortable with, but you
> might be surprised...

I've also used cooperative systems in the past, as well.  Just none
written in Forth.

Quote:
> Our multitasker is normally used in a dedicated, native environment
> where we don't have to worry about arbitrary task behaviors.  Design

Bingo -- this is what I was getting at.  And in this situation,
cooperative multitasking is actually preferred over preemptive because
it is significantly lower overhead.

Quote:
> Probably true, a good rationale for using Forth in such projects :-)

I suspect you are correct.  :)  I would love to use Forth more often.
It's unfortunate that I have been largely unsuccessful in pushing
Forth more successfully at my own work place.

--
Samuel A. Falvo II



Sun, 28 Nov 2004 08:27:20 GMT  
 IDLE-EKEY?

Quote:


> > If you have an infinite loop, what you really have is an inadequately
> > tested system which shouldn't be released in a production environment.

> I *KNEW* this argument would come up sooner or later, and how often it
> is relied upon instead of addressing the problem for what it is.

> I am currently working with hardware with a non-multitasking system of
> any kind right now.  And occasionally, being the imperfect human that
> I am, I end up creating an inadvertent infinite loop.  Rebooting the
> computer to fix the problem is a very lengthy, costly solution to what
> would be a *TRIVIAL* problem in a pre-emptively multitasking
> environment.

> It's especially important when the system in question is open-ended.
> If you cannot control what software the user will use in conjunction
> with your own, you therefore cannot control the security of the system
> as a whole.  No matter how bug-free *YOUR* code is, if my code hangs
> the system, your code fails (to the user, it doesn't matter who's
> fault it is -- all he or she knows is the system is hung solid, and
> (s)he will be right miffed!).

> > But you said you hadn't used a Forth multitasker of the type
> > I'm describing, so you lack at least that experience.  I can
> > certainly see that if you've always used preemption and time
> > slicing that's what you'd feel most comfortable with, but you
> > might be surprised...

> I've also used cooperative systems in the past, as well.  Just none
> written in Forth.

> > Our multitasker is normally used in a dedicated, native environment
> > where we don't have to worry about arbitrary task behaviors.  Design

> Bingo -- this is what I was getting at.  And in this situation,
> cooperative multitasking is actually preferred over preemptive because
> it is significantly lower overhead.

> > Probably true, a good rationale for using Forth in such projects :-)

> I suspect you are correct.  :)  I would love to use Forth more often.
> It's unfortunate that I have been largely unsuccessful in pushing
> Forth more successfully at my own work place.

> --
> Samuel A. Falvo II

Sam,

I ran cooperative multitasking on a Z-80, and occasionally hung it up. A
button connected to NMI put me into the monitor, so I could look and see
why. Apples had an interrupt button next to the reset button. Do they
still?

Jerry
--
Engineering is the art of making what you want from things you can get.



Sun, 28 Nov 2004 09:21:09 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. KEY , EKEY , AND EKEY>CHAR

2. Idle loops - sometimes a little too idle?

3. Idle doesn't Idle

4. 2.3 a1 idle.py vs. idle.pyw

5. EKEY in gforth in DOS

6. EKEY in gforth for linux?

7. KEY and EKEY

8. EKEY>CHAR in Win32Forth

9. portable definitions for KEY and EKEY?

10. EKEY and double numbers

11. EKEY part 3 of 3

12. EKEY part 2 of 3

 

 
Powered by phpBB® Forum Software