John, Your email response to Jason confirmed the following semantics for pipes. >> >> 3. The spec doesn't explicitly define the HW/SW yield control semantics when using pipes. Here is want we understand so far: >> >> Pipe is empty and receive() is called - Yield to producer >> Pipe is full and send() is called - Yield to consumer >> Pipe is not empty and flush() is called - Yield to consumer >> >> Is this correct? Shouldn't the spec define explicitly the above semantics? > >johnS: >Yes this is basically correct. We can add some more descriptive text there. > >-- johnS > I am wondering how the following scenario that uses data shaping would work. I am looking at what you have defined as a nozzle meaning that the BFM (producer) is writing elements one at a time, but the PM (consumer) on the C side is reading the transaction (all the elements) as a whole. 1. Assume that pipe fills up while the producer has provided only part of the elements and thus has not issued yet eom and flush. If this cause the pipe to yield to the consumer (as defined above), the dpi_pipe_c_receive method will still blocked until the entire transaction is being written by the producer. This will result in a deadlock as both sides are now waiting on each other. Is this correct or I misunderstood how data shaping is supposed to work? 2. Assume also that the producer has chosen to call flush before eom for whatever reason. The pipe protocol does not prohibit that by my understanding. Correct? This is the "pipe is not empty; yield to consumer" scenario. But again the consumer dpi_pipe_c_receive call will still block as it is waiting on the entire transaction to be written. What will happen in this case? Thank, Shabtay PS. I'll probably read your response after the holidays. Happy Holidays to everybody.Received on Fri Dec 23 16:23:12 2005
This archive was generated by hypermail 2.1.8 : Fri Dec 23 2005 - 16:23:19 PST