This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cyg_scheduler_lock


> 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.

  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.

  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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]