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/ > _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
