Hi Johny, On Thu, Jun 6, 2013 at 7:46 PM, Johny Mattsson <[email protected]> wrote: > On 7 June 2013 02:56, Miklos Maroti <[email protected]> wrote: >> >> If Tasklets are configured to run in interrupt context, then taking >> the first interrupt (A) we call Tasklet.schedule() which will call the >> Taskletr.run() command immediately, but it remembers internally that a >> tasklet is already running. When a subsequent interrupt arrives (B) >> before (A) has returned, and calls Tasklet.schedule() again, then we >> just remember that Tasklet.run() must be called again, and we >> immediatelly return from the (B) interrupt. When interrupt (A) >> returns, then we check whether there were other interrupts so whether >> we should call Tasklet.run() again. > > I'm curious - which platforms have nested interrupts enabled? In my > experience their usage has always been discouraged (and I ended up not using > them for my Arduino-port-in-progress).
As far as I know, all TINYOS platforms have some nested interrupts enabled (i.e. nonatomic handlers that automatically reenable interrupt in their first instruction). For example, the UART code is such on all platforms as far as I know (and that is why software problems in older versions of the serial stack would hang under high load). > Have there been any measurements done > in terms of performance impact of using interrupt vs TASKLET_IS_TASK? The > typical driver approach of bottom-in-interrupt, top-in-task is after all > designed to ensure device timing constraints are adhered to without hogging > interrupts for too long. A typical tinyos application can have long running tasks, for example some signal processing. There us no way one can mandate that all tasks should be executed in less than 1ms, because that cannot be enforced on a global scale. However, the radios tack with software acks should respond with an ACK to incoming packets withing 0.3-0.6 ms, and this is NOT achievable without handling a significant portion of the radio logic in interrupt context. So for some applications, it makes sense to run tasklets in interrupt context. On the other hand, if some other high priority stuff (e.g. ADC at 40 KHz) is running, then using TASKLET_IS_TASK makes more sense, but that has consequences (larger latency, etc). By the way, hardware ACK is NOT the solution in general, because the software ack makes sure that the mote has enough memory buffer to store the incoming packet, and under hardware ACK the stack might be forced to drop the packet before it can actually notify the AM handler. Think about that too. > With the tasklet stuff it seems that unless nested > interrupts are used (and their priorities managed correctly), one either > runs the risk of blocking other interrupts for potentially a very long time > (as the "dispatcher" does not yield), or not responding to the interrupt in > a timely manner (if a long-running task is currently executing or scheduled > to be executed before the tasklet task). Of course you should enable nested interrupts when the tasklets are running in interrupt context. You do not block other interrupts, because tasklets never disable interrupts, they will just prevent the same tasklet to be run concurrently. Of course running tasklets are blocking the task scheduler, but that is expected and nothing unusual, so yes other tasks can be blocked. I hope this answers your questions. Think of Tasklets as a way to write code that you can configure to your hart content: either to be run as regular tasks, or to run them in interrupt context in a safe way. It just gives the user quite a bit of flexibility. > Thanks for posting the write-up! Can I suggest it be added to the github > wiki, or the regular doc site as well? Sure, would you take this task, and I will extend it as needed? Best, Miklos > > Cheers, > /Johny > -- > Johny Mattsson > Senior Software Engineer > > DiUS Computing Pty. Ltd. > where ideas are engineered _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
