Hi! This is a driver-related question on non-blocking writes and poll. 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)? 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... I'll appreciate any answer, or pointer to relevant information. Thanks Albert -
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.25-rc4 |
| Greg KH | Linux 2.6.25.10 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Ilpo Järvinen | Re: Strange Application bug, race in MSG_PEEK complaints (was: Bug#513695: fetchma... |
