[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] proposed Scheduler interface change

[David Gay]

On 10/15/05, Jan Hauer <jan.hauer at gmail.com> wrote:
> On 10/15/05, David Gay <dgay42 at gmail.com> wrote:
> > On 10/15/05, Philip Levis <pal at cs.stanford.edu> wrote:
> > > On Oct 15, 2005, at 11:20 AM, David Gay wrote:
> > > > Minor related change: __nesc_atomic_sleep should disable interrupts
> > > > after the sleep completes. This isn't really necessary, but it makes
> > > > its use inside an atomic section cleaner.
> > >
> > > I think this is chip-dependent. IIRC, Phil B. had some observations
> > > about this when working on the px, where sleep automatically re-
> > > enabled interrupts? This is what led to the atomic sleep call...
> >
> > That's not the question. The question is, once the sleep completes
> > (presumably because some interrupt just ran), should we redisable
> > interrupts (non-atomically)? I'd say yes, because __nesc_atomic_sleep
> > (implicitly) starts with interrupts off. It's not particularly
> > crucial, though, because you can of course just write:
> >   __nesc_atomic_sleep();
> >   __nesc_enable_interrupts();
>
>
> Looking at the code of Scheduler.taskLoop(), I think it IS crucial
> that __nesc_atomic_sleep(); is followed by a
> __nesc_disable_interrupts();.
> Otherwise this could happen after waking up:

Clearly, I'm not being clear. The answer to the comment above is "Of
course". The only question is: should that __nesc_disable_interrupts
be:
a) inside __nesc_atomic_sleep
b) or, after the call to __nesc_atomic_sleep, inside taskLoop
? (I was arguing for a, i.e., changing the definition of __nesc_atomic_sleep)

David

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg