[ECOS] cyg_scheduler_lock

[ECOS] cyg_scheduler_lock

[Rafael Rodríguez Velilla]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

  I'm reading "eCos Reference Manual" and I see that
cyg_scheduler_lock.
   Locks the scheduler so that a context switch cannot occur. This can
be used to protect data shared between a thread and a DSR, or between
multiple threads, by surronding the critical region with
cyg_scheduler_lock() and cyg_scheduler_unlock().

I don't understand that of protecting data between DSRs and threads?

  If I lock the scheduler during the thread then no DSR can occur, no
other thread can gain the CPU.
  Is it safe to use cyg_scheduler_lock or unlock inside a DSR?


--
Rafael Rodríguez Velilla        rrv@tid.es
Telefónica I+D          http://www.tid.es
Telf: +34 - 91 337 4270

Re: [ECOS] cyg_scheduler_lock

[Jonathan Larmour]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

Rafael Rodríguez Velilla wrote:
> 
>   I'm reading "eCos Reference Manual" and I see that
> cyg_scheduler_lock.
>    Locks the scheduler so that a context switch cannot occur. This can
> be used to protect data shared between a thread and a DSR, or between
> multiple threads, by surronding the critical region with
> cyg_scheduler_lock() and cyg_scheduler_unlock().
> 
> I don't understand that of protecting data between DSRs and threads?

It's only needed in threads, since DSRs may run asynchronously at any point
after an interrupt. The clock interrupt that can cause a reschedule is just
one such interrupt.
 
>   If I lock the scheduler during the thread then no DSR can occur, no
> other thread can gain the CPU.
>   Is it safe to use cyg_scheduler_lock or unlock inside a DSR?

Yes they are safe in a DSR as long as they are balanced (you only lock as
many as you unlock).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] cyg_scheduler_lock

[Hugo 'NOx' Tyson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]


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

>   I'm reading "eCos Reference Manual" and I see that
> cyg_scheduler_lock.
>    Locks the scheduler so that a context switch cannot occur. This can
> be used to protect data shared between a thread and a DSR, or between
> multiple threads, by surronding the critical region with
> cyg_scheduler_lock() and cyg_scheduler_unlock().
> 
> I don't understand that of protecting data between DSRs and threads?
> 
>   If I lock the scheduler during the thread then no DSR can occur, no
> other thread can gain the CPU.

Correct.

The flip side of this is that a DSR can only run (and do things that might
modify kernel variables) when the thread is *not* doing things that modify
kernel variables.

>   Is it safe to use cyg_scheduler_lock or unlock inside a DSR?

DSRs are executed with the scheduler already locked.  That's why DSRs may
only perform producer operations (signal, send, wakeup, setflag) and must
not sleep (get, wait, delay).

Making calls to lock and unlock the scheduler within a DSR is therefore
pointless - but you can call code that does that if you want to share a
routine between the task and the DSR, so long as it counts up (locks) the
same number as it counts down (unlocks).

Performing producer operations does indeed increment and decrement the
scheduler lock, but it must not become unlocked (==0) within the execution
of a DSR.

	- Huge

Re: [ECOS] cyg_scheduler_lock

[Rafael Rodríguez Velilla]

> >   If I lock the scheduler during the thread then no DSR can occur, no
> > other thread can gain the CPU.
> >   Is it safe to use cyg_scheduler_lock or unlock inside a DSR?
>
> Yes they are safe in a DSR as long as they are balanced (you only lock as
> many as you unlock).

  But it must be balanced in each DSR, isn't it? And this makes it completely
unuseful to use this inside DSRs.

Re: [ECOS] cyg_scheduler_lock

[Jonathan Larmour]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

Rafael Rodríguez Velilla wrote:
> 
> > >   If I lock the scheduler during the thread then no DSR can occur, no
> > > other thread can gain the CPU.
> > >   Is it safe to use cyg_scheduler_lock or unlock inside a DSR?
> >
> > Yes they are safe in a DSR as long as they are balanced (you only lock as
> > many as you unlock).
> 
>   But it must be balanced in each DSR, isn't it? And this makes it completely
> unuseful to use this inside DSRs.

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

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] cyg_scheduler_lock

[Rafael Rodríguez Velilla]

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

Re: [ECOS] cyg_scheduler_lock

[Hugo Tyson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

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