Semaphore implementation : why is disabling interrupts required along with test-and-set?

Question

Going over this sample semaphore implementations (for SMP systems), I understand the test-and-set is required for multiprocessor atomic checks. However, once we add the atomic checks aren't the disable interrupts redundant ? The disable interrupts, anyway, only offer atomicity over one processor. Addition to the semaphore queue also needs to be protected.

class semaphore {
private int t;
private int count;
private queue q;

public semaphore(int init)
{
    t = 0;
    count = init;
    q = new queue();
}

public void P()
{
    Disable interrupts;
    while (TAS(t) != 0) { /* just spin */ };
    if (count > 0) {
        count--;
        t = 0;
        Enable interrupts;
        return;
    }
    Add process to q;
    t = 0;
    Enable interrupts;
    Redispatch;
}

public V()
{
    Disable interrupts;
    while (TAS(t) != 0) { /* just spin */ };
    if (q == empty) {
        count++;
    } else {
        Remove first process from q;
        Wake it up;
    }
    t = 0;
    Enable interrupts;
}

}

Strader

This is homework question asking Stack Overflow to do the homework. See "Why do we still have to disable interrupts in addition to using test and set?" in pages.cs.wisc.edu/~bart/537/lecturenotes/s10.html where the code comes from (very likely). The question currently does not fulfill stackoverflow.com/help/on-topic: "Questions asking for homework help must include a summary of the work you've done so far to solve the problem, and a description of the difficulty you are having solving it" – Loreenlorelei

Thanks, @Loreenlorelei - I was just considering answering that. Now it gets down/close. – Disconcerted

This question appears to be off-topic because it is about a homework dump. – Disconcerted

It is not a homework question, I am a professional going over implementations myself and going over various textbooks / slides. And came across this code across multiple books but not one explains why the disabling is required. – Strader

Answer 1

While it is true that turning interrupts off on one processor is insufficient to guarantee atomic memory access in a multiprocessor system (because, as you mention, threads on other processors can still access shared resources), we turn interrupts off for part of the multiprocessor semaphore implementation because we do not want to be descheduled while we are doing a test and set.

If a thread holding the test and set is descheduled, no other threads can do anything with the semaphore (because its count is protected by that test and set) the thread was using while it's asleep (this is not good). In order to guarantee that this doesn't happen we'll turn interrupts on our processor off while using the test and set.

Pedicle

Anne - first of thanks for replying to this question (it was almost dead). Your reply makes perfect sense. To be truly pedantic though, even if a thread was put to sleep before setting t = 0 (unlocking the spinlock), the other threads will still just keep spinning when they try and access the semaphore. This is really bad for performance as it results in wasted cycles but it still is a correct (albeit horrible) solution since no state is corrupted due to any race conditions. Please correct me if I am wrong i.e. disabling interrupts is critical for performance and not for correctness. – Strader

You are correct -- keeping interrupts on would not introduce any synchronization issues, it would just result in poor performance. – Pedicle