OSDev.org

Owen wrote:Think of it as the blocked process "donating its priority and timeslices" in order to be able to get back to its own work ASAP

Brendan wrote:Also, you'll find that "Reschedule()" is called from more than just the timer IRQ - for example, if a thread blocks for any reason (e.g. "sleep()", waiting for file IO, etc) then the kernel code that handles these things will call "Reschedule()" themselves. Once you upgrade to a better scheduling algorithm you'll probably also have cases where a high priority thread unblocks and you want it to preempt the currently running (lower priority) thread; and you'll want to switch directly to the high priority thread (without the extra overhead of deciding which thread to switch to, because you already know).

2. Disable interrupts. This works regardless of where the spinlocks are taken, but cannot handle nesting. It should be avoided if the protected code takes "too long" to execute (bad interrupt latency)

JamesM wrote:

2. Disable interrupts. This works regardless of where the spinlocks are taken, but cannot handle nesting. It should be avoided if the protected code takes "too long" to execute (bad interrupt latency)

Will break in an SMP environment.

There are legitimate situations in which you may need a reentrant spinlock; it's usual to provide a specific lock type for this case.

gerryg400 wrote:Code that disables interrupts should save the old interrupt state during a spin_lock() and restore the state during spin_unlock(). That way spin_locks can be safely nested. Something like this perhaps ....

Code: Select all

static int inline spin_wrlock_irq(spinlock_t volatile *p_slock) {

    int int_enabled = rd_flags() & 0x200 ? 1 : 0;

    __cli();

    spin_wrlock(p_slock);

    return int_enabled;
}

static void inline spin_unlock_irq(spinlock_t volatile *p_slock, int int_enabled) {

    spin_unlock(p_slock);

    if (int_enabled) {
        __sti();
    }
}

You absolutely need to nest spinlocks in an SMP environment if you want to achieve any sort of concurrency. If you don't nest spinlocks then you are arguing for a big kernel lock, or perhaps a few biggish kernel locks.

Recursive spinlocks on the other hand are generally avoidable.

evoex wrote:Wouldn't it be easier/better to store the "int_enabled" state in the spinlock_t type? Then you don't need to store it in a separate variable...

gerryg400 wrote:

Code: Select all

static int inline spin_wrlock_irq(spinlock_t volatile *p_slock) {

    int int_enabled = rd_flags() & 0x200 ? 1 : 0;

    __cli();

    spin_wrlock(p_slock);

    return int_enabled;
}

static void inline spin_unlock_irq(spinlock_t volatile *p_slock, int int_enabled) {

    spin_unlock(p_slock);

    if (int_enabled) {
        __sti();
    }
}

You absolutely need to nest spinlocks in an SMP environment if you want to achieve any sort of concurrency.

int a = spin_wrlock_irq(locka);
int b = spin_wrlock_irq(lockb);
...
spin_unlock_irq(locka, a);  // or even, god forbid: unlock_irq(lockb, a);

eryjus wrote: But,

Code: Select all

int a = spin_wrlock_irq(locka);
int b = spin_wrlock_irq(lockb);
...
spin_unlock_irq(locka, a);  // or even, god forbid: unlock_irq(lockb, a);

... enables interrupts before all the locks are released, and we are back at the same question -- an opportunity to deadlock. To get around this, you would have to maintain a stack of interrupt flag states and pop them off as you unlock the spinlocks to ensure you didn't get into trouble, which feels like brute-force coding.