jeane <[EMAIL PROTECTED]> writes: > On 20 Dec 2005 16:04:55 +0000, Nick Garnett <[EMAIL PROTECTED]> wrote: > > jeane <[EMAIL PROTECTED]> 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 > acceptable(?) > 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 configurations. 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
