This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: regarding hal_interrupt_stack_call_pending_DSRs call


Hi Nick,

> I doubt that there are any more race conditions in
> the SMP code than in the uniprocessor code.
race conditions in uniprocessor code? have there been
in past? but somehow I am not able to comprehend this
idea of race conditions in uniprocessor code? Can
anyone out there help me with an example?

> If I had chose to implement a per-CPU scheduler lock
> with inter-cpu spinlocks
if i guess from the other part of your reply, this or
these? inter-cpu spinlocks will be required for
serialisation purpose? If I am not asking for too
much, may be you can elaborate a bit more on this
aspect? how many of additional inter-cpu spinlocks and
for what purpose wrt per-CPU schedular lock
implementation?

> would be more inclined to agree that there may be
> hidden races, spinlocks and livelocks.
just a curiousity. i presume eCos didn't/doesn't have
deadlocks!! have there been, in past any such kind of
problematic locks and races discussed on list. I think
I should search the archives for these keywords to
find these answers to myself.

> have a dual CPU
> Pentium machine here, but few people will want to
> deploy such a
> monster for embedded applications.
:-) and the possibility for even two cpus in a
handheld device, mobile phone etc. is way way down in
future.. right!

> This can never happen, zero_sched_lock() will only
> be called if the
> CPU has already claimed the scheduler lock. There
> are only three
> places it is called, and these are all in the kernel
in unlock_inner, in thread_entry and if i remember
right unlock_simple??

> There is already an assertion in the
> HAL_SMP_SCHEDLOCK_ZERO() macro
> that tests this.
what i meant was that this won't come into effect
unless i enable asserts.. what i was saying.. if it
could be made part of regular code there.
may be it can make it bad-user-programming-safe also.

> > is   -- programmer's bad programming -- calling
> > reschedule or unlock_reschedule in a code sequence
> w/o
> > taking a schedlock in nearest past to reschedule
> call.
> > 
> > ** assuming sched_lock = 0
> > 
> > ** CPU1 - interrupt came, code went to
> interrupt_end
> > -> unlock_inner -> ... pending_DSRs..
> > 
> > ** CPU2 - code happens to execute
> > reschedule->unlock_inner->context switch call
> > that brings in another thread on CPU2 that falls
> > through it's earlier exceution and zeroes out
> > sched_lock.
> > 
> > ** CPU1 - still in pending_DSRs call and another
> > interrupt has come.
> >
> 
> This cannot happen because CPU2 will be held trying
> to acquire the
> scheduler lock until CPU1's DSR is finished.
probably you missed out something what I had said
above? -- The sched_lock is 1 when code on CPU1 is
processing DSRs. Because programmer hasn't bothered to
take a sched_lock but checked for certain condition
that didn't meet and he called unlock_reschedule or
reschedule to yield control to others (this is
happening on CPU2). now since in reschedule it just
gets the value of current schedlock and proceeds with
call to unlock_inner where eventually context switch
happens and another thread gets loaded which proceeds
with zeroing schedlock. Now on CPU1 code is in DSR
processing and schedlock has become zero. If another
interrupt happens to come on CPU1 now, it will be able
to enter unlock_inner and ..pendingDSRs call again
because schedlock was this time zero again on entry to
interrupt_end.

Right! in this scenarion if problem happens it will be
because of user wrote a bad program and tried to use
the calls like reschedule w/o following proper
protocol of taking schedlock and then calling it, as a
normal rule seen in various synchronisation primitive
code.
right!

I think in this case this discussion is futile. but I
thought to put my 2 cents forward as I have seen in
recent past, mails from people on list, saying that
their customer wanted?doing things in a particular
manner which is kind of not okay.
But if problems come I think customer will toruble the
list-person only.. :-) even though he/she didn't
listen to list-person's advices earlier.

brij



__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]