hi,
Yes if config CONFIG_PREEMPT enabled,even if you dont have an smp
box,we can think of
preemption as equivalent to SMP.correct me if i am wrong about below lockings
if we require locking only in user context: semaphore is preferred
locking between user context(can be kernelpath) and
sofirqs:spin_lock_bh() and spin_unlock_bh()
locking between user context and tasklets:spin_lock_bh() and spin_unlock_bh()
locking between user context and timers:spin_lock_bh() and spin_unlock_bh()
locking between two same tasklets or same timers: not required
locking between two different tasklets or  different timers or
tasklet/timer: spin_lock,spin_unlock
locking between same softirqs: spin_lock,spin_unlock
locking between different softirqs: spin_lock,spin_unlock
locking between hardirq and softirq: spin_lock_irqsave,spin_unlock_irqrestore
locking between two hardirq : spin_lock_irqsave

thanks,
karunakar


On Thu, Nov 10, 2011 at 11:17 AM, Rajat Sharma [off-list ref] wrote:

Hi Dave,

quoted

Also, remember that spin-locks are no-ops on a single processor
machine, so as coded, you have no protection on a single-processor
machine if you're calling from thread context.

Not completely true, spinlock can still provide protection even in
this case i.e. two thread context sharing a resource on UP. Remember
that for peemptive kernel, it disables preemption, so it is guranteed
that scheduler does not through out this thread as long as spinlock is
held.

I agree that a mutex can as well be used for this example but it again
depends on situation, if you want to be quick about your task and are
100% sure that task does not sleep or takes too long processing
cycles, disabling preemption (i.e. spinlock in this case) can be a
better option.

Thanks,
Rajat

On Thu, Nov 10, 2011 at 10:17 AM, rohan puri [off-list ref] wrote:

quoted

On Thu, Nov 10, 2011 at 3:10 AM, Dave Hylands [off-list ref] wrote:

quoted

Hi Kai,

On Wed, Nov 9, 2011 at 1:07 PM, Kai Meyer [off-list ref] wrote:

quoted

When I readup on spinlocks, it seems like I need to choose between
disabling interrupts and not. If a spinlock_t is never used during an
interrupt, am I safe to leave interrupts enabled while I hold the lock?
(Same question for read/write locks if it is different.)

So the intention behind using a spinlock is to provide mutual exclusion.

A spinlock by itself only really provides mutual exclusion between 2
cores, and not within the same core. To provide the mutual exclusion
within the same core, you need to disable interrupts.

Normally, you would disable interrupts and acquire the spinlock to
guarantee that mutual exclusion, and the only reason you would
normally use the spinlock without disabling interrupts is when you
know that interrupts are already disabled.

The danger of acquiring a spinlock with interrupts enabled is that if
another interrupt fired (or the same interrupt fired again) and it
tried to acquire the same spinlock, then you could have deadlock.

If no interrupts touch the spinlock, then you're probably using the
wrong mutual exclusion mechanism. spinlocks are really intended to
provide mutual exclsion between interrupt context and non-interrupt
context.

Also remember, that on a non-SMP (aka UP) build, spinlocks become
no-ops (except when certain debug checking code is enabled).

--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Nice explanation Dave.

Regards,
Rohan Puri

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies