On Aug 31, 2:20 pm, "anon... anon.al" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
