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). 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. 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). Thanks for posting the write-up! Can I suggest it be added to the github wiki, or the regular doc site as well? 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
