Different use of lock in lock_enqueue and lock_dequeue - Minix

This is a discussion on Different use of lock in lock_enqueue and lock_dequeue - Minix ; Hi folks, i am currently working on porting MINIX 3. That's why i was discovering the following question. My question affects funtions in kernel/proc.c. Why does the function lock_dequeue check for reentering, while lock_enqueue doesn't? I'm especially wondering about this ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Different use of lock in lock_enqueue and lock_dequeue

  1. Different use of lock in lock_enqueue and lock_dequeue

    Hi folks,

    i am currently working on porting MINIX 3. That's why i was
    discovering the following question.

    My question affects funtions in kernel/proc.c. Why does the function
    lock_dequeue check for reentering, while lock_enqueue doesn't? I'm
    especially wondering about this fact, since both functions are called
    subsequently by do_clocktick in kernel/clock.c.

    Thanks for your answers!

    Alex

  2. Re: Different use of lock in lock_enqueue and lock_dequeue

    Hm, seems as if my question either was too stupid or too tricky!

    Any ideas?

  3. Re: Different use of lock in lock_enqueue and lock_dequeue

    Hm, seems as if my question either was too stupid or too tricky!

    Any ideas?

  4. Re: Different use of lock in lock_enqueue and lock_dequeue

    A. Schabel wrote:
    > My question affects funtions in kernel/proc.c. Why does the function
    > lock_dequeue check for reentering, while lock_enqueue doesn't? I'm
    > especially wondering about this fact, since both functions are called
    > subsequently by do_clocktick in kernel/clock.c.


    Hi Alex,

    The "k_reenter >= 0" test checks if the current code is running in
    kernel mode (ring 0). In task mode (ring 1), locking consists of
    disabling interrupts. In MINIX3's kernel mode, interrupts are already
    disabled, and must not be enabled by calling unlock().

    The lock_dequeue call needs the kernel mode check because it can be
    called from RTS_LOCK_SET in cause_sig, which in turn can be called from
    the exception handler running in kernel mode. In contrast, lock_enqueue
    is never called from kernel mode, so it does not need this check.

    The do_clocktick call is always executed in task mode (namely, in the
    clock task), so it always needs the locking variants.

    Regards,
    David

  5. Re: Different use of lock in lock_enqueue and lock_dequeue

    Hi David,

    thanks a lot!

    On 23 Jun., 18:05, "D.C. van Moolenbroek" wrote:
    >
    > The do_clocktick call is always executed in task mode (namely, in the
    > clock task), so it always needs the locking variants.


    This was my point of view but with the lack of the absolute truth, it
    was hard/impossible to know why the above functions are implemented
    differently.

    By the way. Are you using Eclipse for the MINIX 3 project at
    university? I couldn't anymore live without. It gives great support in
    terms of locating referenced macros, types, structs, functions an so
    on.

    Best regards

    Alex

+ Reply to Thread