From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugo 'NOx' Tyson To: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] cyg_scheduler_lock Date: Wed, 23 May 2001 10:45:00 -0000 Message-id: References: <3B0BD36B.7F6BE5A@tid.es> X-SW-Source: 2001-05/msg00400.html Rafael Rodríguez Velilla 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