[ECOS] Re: DSR stops running after heavy interrupts. Bug found?

Sergei Organov osv@javad.com
Mon Apr 10 11:15:00 GMT 2006


Nick Garnett <nickg@ecoscentric.com> writes:

> Sergei Organov <osv@javad.com> writes:
>
>> A little OT while we are at interrupt_end(). Could you please explain
>> why
>> 
>> #ifdef CYGPKG_KERNEL_SMP_SUPPORT
>>     Cyg_Scheduler::lock();
>> #endif
>> 
>> is there at the beginning, -- looks like extra scheduler lock without
>> corresponding unlock for SMP case. If not a bug, it seems a comment
>> would be nice to have there.
>
> In SMP configurations we don't want to claim the scheduler lock in the
> interrupt VSR because it would block interrupts and scheduler
> operations on other CPUs. It also requires a spinlock to be claimed,
> which would require special code to be written -- it's much easier to
> do the job later. In HALs where SMP is supported, the usual scheduler
> lock increment is ifdeffed out.

Ah, now I see, thanks. Seems like non-SMP targets could benefit from
this approach as well, isn't it? Or is there some fundamental difference
here?

I just think that SMP variant makes some things better even for
single-CPU case and thus it could be a good idea to use SMP variant for
single-CPU case in those places. Less ifdefs would be another gain.

>
> Perhaps a comment would be useful, but it seemed like the ifdef
> surrounding it would be sufficient indication that this was for SMP
> only.

Please try to look at it from the POW of a reader of the
interrupt_end(), -- it's clear that it's for SMP only, but it's
absolutely unclear why SMP requires one more scheduler lock. When I
looked at it, I failed to find corresponding unlock(), but didn't pay
much attention as I'm not currently interested in SMP.

I believe your above "In SMP configurations we..." phrase would be a
nice comment for this piece of code.

-- Sergei.

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



More information about the Ecos-discuss mailing list