[lkml]   [2007]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Nonblocking call may block in a mutex? Nonblocking call after poll may fail?
    On Aug 31, 2:20 pm, "anon..." <> wrote:
    > Setup:
    > there is a single output-buffer (in kernel-space) of 24 bytes for
    > writes from all processes A, B, and C: each process is restricted to
    > use at most 8 bytes: 8*3 = 24
    > (until that data is handled (interrupt-handler...))
    > Question:
    > If this output-buffer has "4-bytes space remaining for process A",
    > then a non-blocking write of process A could still encounter a locked
    > mutex, if process B is busy writing to the output-buffer.
    > Should process A now block/sleep until that mutex is free and it can
    > access the output-buffer (and it's 4 bytes space)?

    Yes, it should sleep until the mutex is free.

    This can be seen from a code snippet in LDD3 (Linux Device Drivers,
    3rd ed.), on page 153:,0,450

    The code snippet in LDD3 does not contain the following before the while loop:

    if (filp->f_flags & O_NONBLOCK) {
    if (down_trylock(&dev->sem)) {
    return -EAGAIN;

    So a non-blocking process can also sleep (in down) if this type of
    mutex is locked. It may however not block if the output-queue is full.

    > What about a non-blocking (write-) poll of process A: if the poll call
    > succeeds (the output buffer has space remaining for process A), and
    > process A now performs a non-blocking write: what happens if A
    > encounters a blocked mutex, since process B is busy writing to the
    > output-buffer.
    > a) Should A block until the mutex is available?
    > b) Should A return -EAGAIN, even though the poll call succeeded?
    > c) Should it be impossible for this to happen! i.e. -> should process
    > A already "have" the mutex in question, when the poll call succeeds
    > (thus preventing B from writing to the output buffer)
    > For c) What if process A "has" the mutex, but never does the
    > non-blocking write. Then no process can write, since the mutex is held
    > by process A...

    It cannot be b) (same reasoning as above).
    But is it a) or c)...?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-31 16:27    [W:0.025 / U:2.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site