Rafael Rodríguez Velilla <rrv@tid.es> writes:

> > Eh? In what scenario would you want to lock and unlock a different number
> > of times in a DSR? (or strictly why lock/unlock at all, unless this is code
> > shared by a thread).
> 
>   I'm just speculating, I want to write some documentation for the ones that will
> have to program over eCos, maybe that programmer will find useful to use unlock or
> lock inside a DSR, so I want to document in which case this is safe. I don't know
> if it is useful or not.
>   I imagine one scenario for unbalanced calls, an interrupt arrives and the
> programmer wants to put all threads to sleep except one, which will run with the
> scheduler locked till another (different)IRQ arrives, so the programmer decides to
> use lock in the first DSR and unlock in the second.

Locking the scheduler (which wouldn't work anyway) is not the way to do
that.  Use thread priorities; use mutexes; use the thread manipulation
primitives.

There are lots of ways to have an interrupt make a thread run - that's the
whole point of DSRs in the first place!  Stopping a thread asynchonously is
possible too, but maybe a bad idea; surely it's best for the thread to
complete its work then choose to wait for when it's next needed?

For example, it's perfectly OK to use a DSR to signal a semaphore to awaken
a high priority thread which will run exclusively until it chooses to sleep
again because it's the highest priority thread.

Or use a DSR to resume a high priority thread directly; or suspend some
other threads; or change the priority of the thread you want to run now.
Running one thread to the exclusion of all others is what thread priorities
are for!
 
>   I can't find any use to balanced lock-unlock calls inside a DSR (because while
> the DSRs are executed no thread can get the CPU) but maybe the programmer finds
> this useful, so I just write that it is safe to use lock-unlock balanced calls
> inside DSRs.

Balanced calls: it might be useful for using the same routine from a DSR as
you use from a thread.  So it's not illegal.  But you're right that it does
not gain you anything either.

>   I have reviewed the code and I think that calling an unbalanced
> cyg_scheduler_unlock inside a DSR is dangerous, because if an IRQ happens after
> this and the DSRs are still being run, then the DSRs are called again. In the ARM
> implementation, the stack is reinitialized and therefore there shouldn't be two
> simultaneous calls to call_pending_DSRs.

You're absolutely right.

	- Huge