What I meant by that is that the write should not get lost, or reordered, if a read fails.
But if a read fails, you don't remove any data from the buffer, thus no reordering should happen, right? The FIFO in producer/consumer not only avoids reordering, it also avoids losing data.
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.
This is not preserving order (the other is preserved once the data is in the buffer), this if fairness.
I admit that I am not so familiar with our implementation of fibril_condvar to provide an instant proof of its fairness, but it just might be fair due to its use of plain lists of waiters.
Your solution with the atomics reminds me of the ticket spinlock, but again, it would be great if you could integrate it into the existing high-level primitives and make use of it via them, not using it directly in an ADT. I miss the middle layer of abstraction in your code.
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.
This issue is usually solved by providing a constant upper bound on the size of the write that is guaranteed not to be cut off. All you need then is to set the pipe's internal buffer size according to this upper bound (usually the same) to make it work.
For example, in POSIX, since the write() does not warrant that it will always be able to write something, this semantics is an improvement over the general case.
The idea that you don't want to cut off the writer ever (without a reasonable upper bound) can be actually quite unfair to other writers. Just imagine a malicious writer that is about to write a few gigabytes into the pipe using a single call.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
