Producer-Consumer

[Reza_sh]

Hi,

 

I was wondering if it is possible to model the producer-consumer problem using LT (b-transport) when we have 1 producer and 2 consumers? In this case, I guess, we need a buffer in the middle and the producer needs to put the payload in the buffer first. However, if, after putting the payload in the buffer, the producer gets blocked, there would not be any difference between having 1 consumer and 2 consumers. Is that correct?

 

Also, if I want to model it using AT, how can the producer distinguish between the end-req/end-resp of different payloads?

 

Thanks,

Reza

[David Black]

You can definitely model the problem using LT. It's just modeling and you can choose whether to block or not. Your buffer would probably have a depth (possibly infinite). You choose when implementing the b_transport what to do if the buffer is full or empty. You could return an error when getting from an empty buffer. Or you could block and wait for an internal event that you create. It's all up to you.

[Reza_sh]

Thanks David. Consider the following scenario:

 

The producer sends a transaction into the buffer and gets blocked since it is b-transport (correct me if i am wrong here! As I know, in the b-transport, the sender gets blocked to receive the response). None of the consumers consumes the data in the buffer so the producer needs to wait to get a response from the buffer! Thus, the producer can send only one transaction and can send the next transaction only after receiving the response of the first transaction!!

 

Please let me know if my understanding of b-transport interface is correct!

 

Thanks,

[apfitch]

Generally LT connections are strictly point-to-point - so an initiator can call a function in a target, one at a time. As you say, in LT one initiator can only make one function call, which must return before it makes a second function call.

 

If you have two consumers, they must have some routing in-between. The initiator calls b_transport in the router (point-to-point); the router inside its implementation of b_transport must interpret the address, call b_transport in the appropriate consumer, and wait. It cannot return to the original initiator until the downstream consumer had returned.

 

There's a comment in the 1666-2011 standard

 

"Although the initiator thread may be blocked, another thread in the initiator may be permitted to call b_transport before the first call has returned, depending on the protocol."

 

Though an initiator with 2 threads could be regarded as two separate but highly co-ordinated initiators in a sense

 

Alan

[Reza_sh]

Thank you Alan.

 

Modeling the producer-consumer problem using AT coding style, when we have 1 producer 1 consumer, we implicitly consider a buffer in the middle since we have concurrency in AT coding style. So, when the producer receives the End_Req, it can initiates a new transaction and send it to the consumer. The consumer puts the payload into its PEQ and consumes it at a certain time. Thus, we can define the size of the buffer by controlling the number of concurrent messages we can have in the system. Using this idea (hopefully it is correct!), I want to model a SysC TLM program when we have 1 producer 2 consumers. However, when the producer receives the response, he does not know whose response that is. In other words, the producer cannot distinguish between the transactions sent by the consumers. 

 

Is there any way that the producer can find out who the sender of each transaction is?

 

Thank you,

Reza

[apfitch]

I think the issue is your statement "So, when the producer receives the End_Req, it can initiates a new transaction".

You shouldn't be creating a new transaction, you should be returning a handle to the original transaction object. The transaction object must remain alive during the complete transaction.

 

You can then tell which transaction object is which by keeping an array of addresses of transaction objects as you create them, and then matching the objects,

 

Alan