[9fans] Interrupted alarm(2) - Plan9

This is a discussion on [9fans] Interrupted alarm(2) - Plan9 ; I’ve been simulating preemptive multithreading using alarm(2) notes and lots of stack smashing. (I’ll have some questions about that later, if things don’t go smooth.) Anyhow, my taskfork looks like: void taskfork(ulong flags) { long quantum; ... quantum = alarm(0); ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: [9fans] Interrupted alarm(2)

  1. [9fans] Interrupted alarm(2)

    I’ve been simulating preemptive multithreading using alarm(2) notes
    and lots of stack smashing. (I’ll have some questions about that
    later, if things don’t go smooth.)

    Anyhow, my taskfork looks like:
    void
    taskfork(ulong flags)
    {
    long quantum;

    ...

    quantum = alarm(0); // stop timer and save time left

    ...

    // back to our regularly scheduled programming...
    alarm(quantum == 0 ? 1 : quantum);
    }
    I included that ugly last line on the off chance that taskfork() is
    called with less than a millisecond left and so alarm(0) will return
    0. Is this neccessary, or can alarm(0) not ever return 0? Would it
    be better to write:
    if(quantum)
    alarm(quantum);
    else
    postnote(PNPROC, getpid(), "alarm");
    }

    --Joel


  2. Re: [9fans] Interrupted alarm(2)

    Use the source, Luke!

    > // back to our regularly scheduled programming...
    > alarm(quantum == 0 ? 1 : quantum);
    > }
    > I included that ugly last line on the off chance that taskfork() is
    > called with less than a millisecond left and so alarm(0) will return
    > 0. Is this neccessary, or can alarm(0) not ever return 0? Would it
    > be better to write:


    Certainly I would guess that alarm(0) returning 0 is a perfectly
    reasonable thing to do, if the alarm was either imminent or
    not scheduled in the first place.

    System calls are implemented in /sys/src/9/port/sys*.c, by
    functions named sysfoo for the call foo. In this case sysalarm
    just calls procalarm, which is in /sys/src/9/port/alarm.c.
    Inspecting that, it is clear that alarm(0) can in fact return 0
    in the two cases I just mentioned. Perhaps more worrying,
    it looks like it can also return a negative number if the alarm
    time has passed without the alarm actually going off.
    And it might not even be the right negative number.

    I also don't see anything that keeps one from scheduling
    alarms at times in the past, though they will just be treated
    as happening as soon as possible (e.g., alarm(-100) looks
    like it will cause an alarm to go off at the next clock tick).

    It also looks like the delivery of alarms can be stopped by a
    single rogue process that can manage to make its p->debug
    qlock unlockable and then schedule a quick alarm to get to
    the front of the alarm queue. Making p->debug unlockable is
    easy: one way is to arrange that the demand load fault caused
    by memmove in case Qnote in procread causes i/o to a file
    server that sits on the request. Then there will be no more
    alarms delivered anywhere in the system until that i/o finishes.
    This may be less than ideal.

    Then again, the whole idea of alarms is broken if you are
    depending on them for very much at all, so the fact that the
    implementation is also a little broken probably doesn't matter.

    Russ

+ Reply to Thread