Re: spin lock

Marcel Hendrix wrote:
Elizabeth D Rather <eratherXXX@xxxxxxxxx> writes Re: spin lock
[..]
Marcel Hendrix wrote:
Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote Re: spin lock
[..]
What happens if a task has the lock/variable and interrupt code needs it?
The interrupt has to silently fail then? Or should the design be that it
can (almost) always run and wake a dedicated, pausable,TASK to further handle the problem? (This postpones the problem until it becomes a real error).

If a task is requesting service from a shared device, it should GET the device before making the service request, then sleep. Interrupt code can complete the time-critical part of the service, then RELEASE the device and awaken the task to do further processing, if any.

Neat. That would save an extra task, but if the interrupt for some reason
does not come because it is missing a period, the system might need to be
aborted.

I suppose some devices might need a time-out. That's not been my experience, though.

It should never happen that a totally unexpected interrupt occurs for a shared device. Some task should be expecting it, having done a GET. A nice side-effect of this scheme is that the GET associates the task handle with the facility, so the interrupt code knows who is expecting the interrupt and hence whom to wake up.

Wouldn't it be rather dangerous for the IRQ handler to do this? The task
could be in the (interrupted) process of being woken up because of a time
out, kill or something... Stopping the IRQ would kill the task, while
stopping the task might not prevent the IRQ from waking it inappropriately.

"Waking up a task" from an IRQ merely involves setting a code in its status cell. It's pretty non-violent, and if the task is already waking up it's a no-op. And we don't kill tasks. We do have a word:

: NOD ( -- ) BEGIN STOP AGAIN ;

....which you can assign a task to do when it isn't doing anything else, in case an interrupt it's associated with wakes it up inappropriately. But normally the task wouldn't GET a facility unless it expected to do something with it.

I see the SwiftForth reference manual has a good discussion on GET and RELEASE.

Yeah, they work pretty much the same in SwiftForth, although the multitasking is completely different. The SwiftOS multitasker is found in SwiftX targets.

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."
==================================================
.

Relevant Pages

  • Re: wake up from a serial port
    ... UART can wake up your system, then using this patch and the command above ... from suspending it during suspend and then an interrupt from this UART ...
    (Linux-Kernel)
  • Re: UCB1400 touch resume
    ... Not sure what you mean by "wake up touch", ... the bootloader runs first - not an interrupt service routine. ... > The regular touch on the TOuch Screen cause the TOCUH IRQ togling 400us, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Forth as an operating system
    ... whereas an interrupt is a one-shot event handler that performs ... wakes up the task that uses the results of the ISR. ... The typical code to wake up a task is: ... mentions would become dedicated hardware. ...
    (comp.lang.forth)
  • Re: [kvm-devel] [PATCH 10/13] KVM: Wire up hypercall handlers to a central arch-independent
    ... doesn't have to wake up again when the timer fires. ... every such interrupt, but just do the right thing for all pending work) ... That's what Xen does (I'm not sure about the timer, but they do avoid unnecessary interrupts). ... As you can have memory shared between the guest and host, ...
    (Linux-Kernel)
  • Re: spin lock
    ... The interrupt has to silently fail then? ... Some task should be expecting it, ... Wouldn't it be rather dangerous for the IRQ handler to do this? ... Stopping the IRQ would kill the task, ...
    (comp.lang.forth)