Quoted from «Linux Device Drivers», by Jonathan Corbet, Alessandro Rubini and Greg Kroah-Hartman:

If a nonpreemptive uniprocessor system ever went into a spin on a lock, it would spin forever; no other thread would ever be able to obtain the CPU to release the lock (because it couldn t yield). Because of this, spinlock operations on uniprocessor systems without preemption enabled are optimized to do nothing, with the exception of the ones that change the IRQ masking status (in Linux, that would be spin_lock_irqsave()). Because of preemption, even if you never expect your code to run on an SMP system, you still need to implement proper locking.

If you re interested in a spinlock that can be taken by code running in interrupt context (hardware or software), you must use a form of spin_lock_* that disables interrupts. Not doing so will deadlock the system as soon as an interrupt arrives while you have entered your critical section.

If you were to use spin_lock() on a non-preemptive kernel to shield data against an interrupt handler, you d deadlock (on a single-processor machine).

If the interrupt handler runs while other kernel code holds the lock, it will spin forever, as there is no way for the regular kernel code to resume and release the lock.

Spinlocks can only be used if the lock holder can always run to completion.

The solution for a lock that might be wanted by an interrupt handler is to use spin_lock_irqsave(), which disables interrupts while the spinlock is held. With 1 cpu, no interrupt handler can run, so there will not be a deadlock. On smp, an interrupt handler might start spinning on another cpu, but since the cpu holding the lock can t be interrupted, the lock will eventually be released.

To answer the two parts of your question:

Even on non-preemtive kernels interrupt handlers may still be executed for example ...

spin_lock() isn t supposed to protect against interrupt handlers - only user context kernel code. spin_lock_irqsave() is the interrupt-disabling version, and this isn t a no-op on a non-preemptive uniprocessor.

...or I might call a function that would put the original thread to sleep.

It is not allowed to sleep while holding a spin lock. This is the "Scheduling while atomic" bug. If you want to sleep, you have to use a mutex instead (again - these aren t a no-op on non-preemptive uniprocessor).

By definition, if you re using a non-preemptive kernel, you won t be preempted. If you do your own multitasking, that s not the kernel s problem; that s your problem. Interrupt handlers may still be executed, but they won t cause context switches.