On 1/30/06, Alfredo Quesada <[EMAIL PROTECTED]> wrote: > So as I'm understanding "events" are generated by > other "internal" tasks, and so they can't stop the > current executing task in any way (I suppose events > join to the task queue at the firsts places, in front > of "normal" tasks instead of joining at the end of the > queue as common tasks should do, so they receive a > special treatment because they need to be executed > "before/faster than common tasks").
Pretty close, except there is only one task queue. Tasks that happen to signal events get no special priority handling. One task is the same as any other task, at all levels in the operating system. > But "async events" may be related to hardware > interrupts, and so they really can get the control in > any moment, "interrupting" any task in any moment if > necesary. > > Is it rigth? Exactly right. > If so you don't need atomic blocks if you don't need > to get involved with async events. Yes. If you have a variable that is never modified in an "async event" (or "async command"), then you never need to protect it with an atomic section. > So the final question is: > Interrupts are disabled while you're running atomic > blocks? because if this is true then you shouldn't be > able to get an incoming packet notification and the > packet should be lost (as I thought it was working..). "Disabling interrupts" only means that *invocation* of interrupt handlers is disabled. Any incoming interrupt is marked pending by the microcontroller and executes as soon as the outer-most atomic section closes. No packets are dropped unless your atomic section is so extremely long that the radio chip FIFO overflows, for instance. > Regards :D Cory > --- Cory Sharp <[EMAIL PROTECTED]> escribió: > > > Alfredo, that's almost exactly right. To make your > > statement precise, > > replace your use of "event" with "interrupt". > > > > Interrupts come from hardware and have further > > interrupts disabled > > during their execution. There is a distinction > > between "events" and > > "async events". "events" may only be signalled from > > tasks and are in > > task context. "async events" may be signalled from > > either tasks or > > interrupts, so they may actually be executing in > > either task or > > interrupt context. When producing warnings, nesC > > just assumes the > > worst. > > > > Cory (tinyos-help cc'ed) > > > > On 1/30/06, Alfredo Quesada <[EMAIL PROTECTED]> > > wrote: > > > So.. if interrupts are disabled when running code > > for > > > events you never need an atomic block there, isn't > > it? > > > that is, you only need atomic blocks at tasks when > > the > > > variable that you want to access can be modified > > at an > > > event, and never more.. ok? > > > > > > thx for posting :) > > > > > > --- Cory Sharp <[EMAIL PROTECTED]> escribió: > > > > > > > Alfredo, > > > > > > > > As long as you only ever update your neighbor > > table > > > > in task context > > > > (synchronous context) you don't need an atomic > > > > block. Task execute on > > > > a first-come first-serve basis. Tasks never > > preempt > > > > other tasks, the > > > > currently running task must complete before the > > next > > > > task can begin. > > > > That is to say, all tasks are atomic with > > respect to > > > > each other. You > > > > don't need an atomic block, so the underlying > > > > interrupt system can > > > > run.. err.. uninterrupted :). > > > > > > > > Cory Sharp <[EMAIL PROTECTED]> > > > > > > > > On 1/27/06, Alfredo Quesada > > <[EMAIL PROTECTED]> > > > > wrote: > > > > > Hi > > > > > > > > > > As you know you can post tasks in order to run > > > > them > > > > > "when it's possible". > > > > > > > > > > I'd like to know if there's any way to send to > > > > sleep a > > > > > task. Let's take a look at an example > > situation of > > > > > what I'm talking about. > > > > > > > > > > Let's imagine a neighbor table, that you're > > going > > > > to > > > > > update (maybe refresh timestamp, or clear old > > > > > entries..). While checking the table you must > > keep > > > > the > > > > > data consistent, so you have at least 2 ways: > > > > > 1. Keep the updating code inside an atomic > > block. > > > > > Doing this way you could even loose packets, > > > > because > > > > > interrupts are disabled and the transceiver > > can't > > > > > notify of an incoming packet. > > > > > 2. Protect the same code for example with > > > > something > > > > > similar to semaphores. The code for getting it > > is > > > > > easy, and you can reduce the size of atomic > > blocks > > > > > (you should only use them when updating the > > > > semaphore > > > > > status). > > > > > > > > > > The problem for the second option is that only > > > > works > > > > > if you can "send to sleep" the current task > > and > > > > give > > > > > the control to another one (at least for a > > short > > > > > period of time). Of course It's only possible > > if > > > > > tinyOS is a multitask OS.. > > > > > > > > > > So.. can this (or something similar) be done > > in > > > > > tinyOS? > > > > > > > > > > regards :D > > > > > > > > > > > > > > > > > __________________________________________________ > > > > > Correo Yahoo! > > > > > Espacio para todos tus mensajes, antivirus y > > > > antispam ¡gratis! > > > > > Regístrate ya - > > http://correo.espanol.yahoo.com/ > > > > > > > _______________________________________________ > > > > > Tinyos-help mailing list > > > > > [email protected] > > > > > > > > > > > > > > > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > > > > > > > > > > > __________________________________________________ > > > Correo Yahoo! > > > Espacio para todos tus mensajes, antivirus y > > antispam ¡gratis! > > > Regístrate ya - http://correo.espanol.yahoo.com/ > > > > > > > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam ¡gratis! > Regístrate ya - http://correo.espanol.yahoo.com/ > _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
