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.
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?
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.
I really don't see any fundamental reason why this should be impossible to implement using mutexes and condition variables. (Semaphores might be handy, but they are not necessary, since the common synchronization primitives are convertible to each other).
It is used only for implementation of pipe, which can be viewed as a high-level synchronization primitive.
No, you are mixing different levels of abstraction. A pipe is not a synchronization primitive, it is an abstract data structure.
Your sleep and wakeup calls are used _only_ for the implementation of this pipe. If you want to make me merge it, please use our existing synchronization primitives for the pipe. Then feel free to reimplement these existing synchronization primitives using sleep and wakeup.
As I answered to Jakub. I will provide a prototype of subjectively better list library as well.
OK. If your list prototype gets merged and then you convert your local list implementation to it, the problem should be solved for everybody.
Yes, I can see how it simplifies stuff. The documentation of async_exchange_begin() should be changed to reflect this. I.e. instead of saying "returns NULL on error", it should say "NULL is considered a valid exchange and the rest of the framework handles this value properly".
+1 M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
