This is the mail archive of the
mailing list for the eCos project.
Re: newbie query! spinlocks mlqueue
jeane <email@example.com> writes:
> On 20 Dec 2005 16:04:55 +0000, Nick Garnett <firstname.lastname@example.org> wrote:
> > jeane <email@example.com> writes:
> > > bonjour!
> > > I was browsing through the code looking for implemantation pour the
> > > spinlock in uni-processor modes. All it does is is add one to the
> > > flag! What happens if there are two threads (with mlqueue based
> > > scheduling preemption enabled) and thread A acquire spinlocks and gets
> > > scheduled out and thread B tries to acquire the spinlock ? It look it
> > > will acquire the spinlock :-S I miss something? how does spinlock
> > > (cyg_spinlock_spin)disables scheduling?
> > > Excuse my poor englais, any help will be grateful.
> > > Thank you,
> > > Jeane.
> > Take a look at the spinlock documentation, it explains there the
> > situations in which spinlocks are appropriate and the potential
> > pitfalls of using then inappropriately:
> > http://ecos.sourceware.org/docs-latest/ref/kernel-spinlocks.html
> > --
> > Nick Garnett eCos Kernel Architect
> > http://www.ecoscentric.com The eCos and RedBoot experts
> Hello Nick,
> Thanks for the link I went through it, I'm new to ecos my assumption
> was while using a spin-lock
> a)a thread should not hold spin-lock for a very long time.Few CPU
> instruction to insert / delete node from a linked list etc. are
> b) No voluntary yielding of thread should happen if the spin-lock is held(?).
> Now my query is :)
> I went through the spinlock's implementation on uni-processor I didn't
> see any while loop /test_and_set instruction in Cyg_SpinLock::lock()
> which will amount to the CPU spinning. Neither was there an
> implementation which will disable scheduling. So how does the uni
> -processor spin-lock guarantee "locking" across threads when
> pre-emptible scheduling is enabled.
> My package configuration enables multilevel queue scheduling and
> pre-emption for uni-processor.
Spinlocks are really only used in eCos for synchronization between
CPUs in an SMP configuration. They are mainly present to control
sharing between CPUs running ISRs and CPUs running threads. They are
not appropriate for synchronization between threads. Synchronization
between threads should use mutexes or other synchronization
primitives, which all function correctly in uniprocessor and SMP
The uniprocessor versions of spinlocks are only really present so that
the same system code can be used for SMP and uniprocessor systems
without change. They track the lock and unlock operations and contain
assertions simply to ensure that any changes for uniprocessor systems
do not introduce gross bugs into the SMP systems.
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