RE: [sv-ec] Strict FIFO ordering of mailboxes try_put/try_get

I didn't get to discuss this at the face-to-face, nor have I received
any more feedback on this.

The LRM says:

"If the mailbox is empty, then the method returns 0. If the type of the
message variable is not equivalent to the type of the message in the
mailbox, the method returns a negative integer. If a message is
available and the message type is equivalent to the type of the message
variable, the message is retrieved, and the method returns a positive
integer."

The LRM does not cover the case when the mailbox is NOT empty AND the
message is NOT available. What would "NOT available" mean?
   

Here's a simple example:
----------------------------------
module top;
   mailbox #(int) m = new(4);


   initial begin : block1
      int i;
      m.get(i);
      $display("%m got %0d at %t",i,$time);
   end : block1
   initial begin : block2
      int i;
      #5 m.put(1); // put after get
      if (m.try_get(i))
	  $display("%m try_got %0d at %0t",i,$time);
      else
	  $display("%m try_get failed at %0t with %0d items in
mailbox",$time, m.num());
   end : block2
endmodule : top
--------------------------------------------------------------------

Do implementations match user's expectations?

I believe that if try_get() is allowed to fail, we must have a delete()
method to flush the mailbox.
Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Rich, Dave
> Sent: Wednesday, February 14, 2007 11:33 AM
> To: Neil.Korpusik@Sun.com
> Cc: sv-ec@server.eda-stds.org
> Subject: RE: [sv-ec] Strict FIFO ordering of mailboxes try_put/try_get
> 
> > >
> > >Dave,
> >
> >Is there a big problem with the rule being that a try_get() succeeds
if
> and >only if BOTH the mailbox queue size is greater than 0 AND the
queue
> of >processes suspended on a blocking get has a size of 0?
> >
> >Mark
> 
> 
> To answer Mark's earlier question, the big problem is that the current
> LRM says that try_get() fails only if the mailbox is empty, or if the
> semaphore does not have enough keys. That says to me that it is
> pre-emptive. Of course, I'm interested in what the intent is and
fixing
> the LRM to match it.
> 
> But here another situation. Suppose I want to implement a flush or a
> drain of a mailbox with
> 
> begin
> 
> 	while (try_get(t));
> 		do_somthing_with(t); // do nothing for a flush
> 	ask_for_more(();
> end
> 
> 
> The ask_for_more() statement is under the assumption that mailbox has
> been emptied. How can you ensure that the flush or drain executes
unless
> try_get is preemptive?
> 
> Dave
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.