This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: cyg_scheduler_lock
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