Re: [ECOS] cyg_scheduler_lock

[Hugo 'NOx' Tyson <hmtx@redxhatx.com>]

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