On 17 September 2013 16:41, Martin Decky <[email protected]> wrote: > Some of the reasons: In pipe, both readers and writers must wait for its >> counterpart. >> > > Of course, this is a bounded producer/consumer with a buffer size of 1. > However, as this usually leads to very large overhead and poor performance, > most pipe implementations use a reasonably larger buffer. The size of the > buffer can also be configurable. > > Using big buffer might help, but see bellow for another problem.
> > Additionally, write must restart if corresponding read >> fails, and in such case it should be returned directly to the head of >> the writers queue (not possible with condvar) >> > > "Corresponding read fails"? How do you define corresponding writes and > reads if both the writer and the reader can write and read arbitrary and > independent amount of data in each call? > > What I meant by that is that the write should not get lost, or reordered, if a read fails. May be avoidable by other means, remember that I have not written the code yesterday. You lost me totally with the "return to the of the queue". But in general > the condition variable in the producer/consumer pattern is used just for > signalling. It has nothing to do with the complexity of the actual > condition or with the order in which you put the data into the buffer. > So, suppose multiple writers are waiting for a buffer space to free up. It's a FIFO, so writers should be let to write in the order they arrived. In general condition variable does not deal with such ordering. Suppose you do not care about the ordering of writers that are waiting. Every writer has a different size of write it needs to make, and you don't want to cut off the data arbitrarily, not when multiple writers are competing for the channel. Then you need to know what amount of buffer space the next writer will need, but you don't know which writer is the next one to wake up. I don't see how to work around that. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
