Re: Nonblocking call may block in a mutex? Nonblocking call after poll may fail?

["anon... anon.al" <anon.asdf@gmail.com>]

On Aug 31, 2:20 pm, "anon... anon.al" <anon.a...@gmail.com> 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:

http://lwn.net/images/pdf/LDD3/ch06.pdf#page=19&zoom=80,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)...?

Regards,
Albert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/