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

Stu,

Based on your feedback and Neil's, I think I misunderstood Dave's point.
The queue maintained by the mailbox *should* be FIFO, which means that
any previous call to get() - already in the mailboxe's queue - should
get priority over a new call to get() - not yet in the queue. What I
meant to say is that we should not standardize the order in which
multiple try_put() calls deposit messages in the queue, that is, waiting
for the writing end of the channel need not be FIFO. 

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Stuart Sutherland
Sent: Tuesday, February 13, 2007 8:10 PM
To: Neil.Korpusik@Sun.com; 'Rich, Dave'
Cc: sv-ec@eda-stds.org
Subject: RE: [sv-ec] Strict FIFO ordering of mailboxes try_put/try_get


I agree whole heartedly with Neil.  The odd behavior of a get bypassing
the
queue when other gets are in the queue is not at all intuitive.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Neil Korpusik
> Sent: Tuesday, February 13, 2007 3:43 PM
> To: Rich, Dave
> Cc: sv-ec@server.eda-stds.org
> Subject: Re: [sv-ec] Strict FIFO ordering of mailboxes try_put/try_get
> 
> I believe that most users would expect requests to be queued up in the
> order in which they were received. It is more work for the vendors to
> support this approach, but it is what I think most users would want.
> 
> Neil
> 
> 
> 
> Rich, Dave wrote On 02/13/07 08:58,:
> > I didn't get a response to this. I'm going to go with the assumption
> > that try_put/try_get can preempt a waiting put/get.
> > 
> >  
> > 
> > We might want to clarify that strict FIFO order apples only after a
> > successful try.
> > 
> >  
> > 
> > Dave
> > 
> >  
> > 
> >  
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > *From:* owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org]
> > *On Behalf Of *Rich, Dave
> > *Sent:* Friday, February 02, 2007 10:48 AM
> > *To:* sv-ec@server.eda-stds.org
> > *Subject:* [sv-ec] Strict FIFO ordering of mailboxes try_put/try_get
> > 
> >  
> > 
> > This is related to a discussion with semaphores a few years back
> > http://www.eda-stds.org/sv-ec/hm/2651.html
> > 
> >  
> > 
> > 14.3.4 says
> > 
> >  
> > 
> > The try_put() method stores a message in the mailbox in strict FIFO
> > order. This method is meaningful
> > 
> > only for bounded mailboxes. If the mailbox is not full, then the
> > specified message is placed in the mailbox,
> > 
> > and the function returns a positive integer. If the mailbox 
> is full, the
> > method returns 0.
> > 
> >  
> > 
> >  
> > 
> > Is the strict ordering only with other try_put()'s or if 
> another put()
> > is blocked waiting for space, must the put() be unblocked 
> before try_put
> > could succeed? Same question for try_get. Must a waiting get be
> > unblocked before try_get could succeed?
> > 
> >  
> > 
> > Dave
> > 
> >  
> > 
> >  
> > 
> > David Rich
> > Verification Technologist
> > Design Verification & Test Division
> > Mentor Graphics Corporation
> > dave_rich@mentor.com
> > Office:   408 487-7206
> > Cell:     510 589-2625
> > 
> >  
> > 
> > 
> > -- 
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* 
> <http://www.mailscanner.info/>*, and is
> > believed to be clean.
> > -- 
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* 
> <http://www.mailscanner.info/>, and is
> > believed to be clean. *
> 
> -- 
> ---------------------------------------------------------------------
> Neil Korpusik                                     Tel: 408-720-4852
> Senior Staff Engineer                             Fax: 408-720-4850
> Frontend Technologies - ASICs & Processors (FTAP)
> Sun Microsystems
> email: neil.korpusik@sun.com
> ---------------------------------------------------------------------
> 
> 
> 
> -- 
> 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.


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