AW: [ECOS] Blocking restricted in DSRs

AW: [ECOS] Blocking restricted in DSRs

[Neundorf, Alexander]

 
> Things like waiting for a semaphore. Blocking is something you do at
> thread level. The thread "blocks" (or goes to sleep) until another
> thread or interrupt wakes it up again. Basically, this waking 
> up is done
> by the scheduler, which explains why you should not block in a DSR,
> which is called _before_ the scheduler. 
> 
> Hope this makes it a little bit clearer,
> 
> Bob

Ok, the docu says sending signals to condition variables is ok from a DSR. But AFAIK this has always be done together with locking the associated mutex first... from the DSR then. But the docu also says using cyg_mutex_lock() should be used only from thread context, not from DSR. So, what's the right way then ?

Alex

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: AW: [ECOS] Blocking restricted in DSRs

[Nick Garnett]

"Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> writes:

>  
> > Things like waiting for a semaphore. Blocking is something you do at
> > thread level. The thread "blocks" (or goes to sleep) until another
> > thread or interrupt wakes it up again. Basically, this waking 
> > up is done
> > by the scheduler, which explains why you should not block in a DSR,
> > which is called _before_ the scheduler. 
> > 
> > Hope this makes it a little bit clearer,
> > 
> > Bob
> 
> Ok, the docu says sending signals to condition variables is ok from
> a DSR. But AFAIK this has always be done together with locking the
> associated mutex first... from the DSR then. But the docu also says
> using cyg_mutex_lock() should be used only from thread context, not
> from DSR. So, what's the right way then ?

It also says that cyg_mutex_signal() can be called without locking the
associated mutex first. This is how it must be used from the DSR.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: AW: [ECOS] Blocking restricted in DSRs

[Nick Garnett]

"Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> writes:

> ...
> > Threads can call blocking functions with the scheduler locked. The
> > lock is essentially a per-thread variable so when the thread is
> > resumed the lock is returned to its former value.
> 
> IOW cyg_scheduler_lock() ensures that the scheduler doesn't run as
> long as the thread which called cyg_scheduler_lock() doesn't call a
> synchronization function which calls itself the scheduler, right ?
>

Correct.

> But still I don't understand the code.  cyg_scheduler_lock() calls
> Cyg_Scheduler::lock() in sched.inl, which calls
> inc_sched_lock(). This I find in smp.hxx. I don't see any thread
> specific data there, so how can this act thread-specific ?

The next lock value is passed as an argument to unlock_inner() and is
therefore saved across the context switch on the stack and set when
then thread is rescheduled. That is why I said "essentially", since it
is not stored explicitly in the thread object.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

AW: [ECOS] Blocking restricted in DSRs

[Neundorf, Alexander]

...
> Threads can call blocking functions with the scheduler locked. The
> lock is essentially a per-thread variable so when the thread is
> resumed the lock is returned to its former value.

IOW cyg_scheduler_lock() ensures that the scheduler doesn't run as long as the thread which called cyg_scheduler_lock() doesn't call a synchronization function which calls itself the scheduler, right ?

But still I don't understand the code.
cyg_scheduler_lock() calls Cyg_Scheduler::lock() in sched.inl, which calls inc_sched_lock(). This I find in smp.hxx. I don't see any thread specific data there, so how can this act thread-specific ?

Thanks
Alex

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss