Re: [Gems-users] MessageBuffer enqueue method

[Milo Martin <milom@xxxxxxxxxxxxx>]

Liqun is right that Ruby is using some sort of smart pointer.

Let me give some more background as to why it does.  Basically, in  
Ruby various types of messages are passed around the system and even  
sent to multiple destinations that may consume the message in any  
order, which creates a tricky situation of deallocating memory.  One  
option would be to make copies of messages as they move around the  
system.  However, as not all messages are the same size and such,  
this would require more memory allocation and deallocation.
The solution we implemented was to use a reference counted smart  
pointer class called "RefCnt".  Each time a copy of this smart  
pointer is copied the reference count is incremented.  Each time a  
smart pointer goes out of scope, the reference count is decremented.   
When the reference count goes to zero, the object is deleted.  One  
important thing is that the reference count must live with the object  
being pointer to, not the smart pointer itself.  As such, the  
reference count is a member of any "RefCountable" object using C++  
inheritance.  That is, all object you want to be able to reference  
count must have RefCountable as a base class.  As such, all messages  
inherit from RefCountable.
It took us a bit to get it figured out and work when we first wrote  
this code.  However, since then it is pretty much invisible.  SLICC  
hides most of the lowest level boxing and unboxing of messages and  
even the networking code is written in a way that is mostly oblivious  
to the reference counting issues.  At this point, it mostly just  
works.  However, if you peel back the layers of the onion, you'll see  
some sort of confusing stuff.
To make things just a bit more confusing, each class of message uses  
their own pool allocator (the Allocator class) to reduce allocation  
and deallocation overheads.
This is actually one of the few places in Ruby that we really make  
use of some advanced C++ features, and hopefully this message helps  
explain what and why Ruby does so.
- Milo

On Aug 7, 2007, at 12:26 PM, Liqun Cheng wrote:

> This is a smart pointer, in which operators (), -> are overloaded.
> Here is an article on smart pointers: "Smart Pointers - What, Why,  
> Which?"
> http://ootips.org/yonat/4dev/smart-pointers.html
>
> Liqun
>
> On 8/7/07, Mike Marty <mikem@xxxxxxxxxxx> wrote: I think this is  
> just C++ magic where calling enqueue() with a sub-class
> of class Message will just invoke the RefCnt(TYPE) constructor.
>
> Other C++ experts can correct me or elaborate.
>
> --Mike
>
>
> selcuk koyuncu wrote:
> > hi everybody,
> >   i ve got  a question about MessageBuffers enqueue method and  
> how it is called from Sequencers.
> >   "MessageBuffer::enqueue(const MsgPtr &msg, ....)"   this method  
> needs an address of MsgPtr type as the first parameter from where  
> we call it,
> > but in Sequencer.C file  its been called with "msg" variable  
> which is a "CacheMsg" object, instead of  a "MsgPtr" object.
> > (CacheMsg msg; ......... >> m_L1Cache_mandatoryQueue_vec 
> [version].enqueue(msg,...));
> >
> >   CacheMsg is derived from  "class Message" and  MsgPtr   
> ("typedef RefCnt<Message> MsgPtr" ) uses "Message" as a template,
> > how this could be possiable to call enqueue method with a  
> CacheMsg object, what do i miss, i think, even a key word can help  
> for figure it out.
> >   garcias,
> >
> >
> >
> > ---------------------------------
> > Ready for the edge of your seat? Check out tonight's top picks on  
> Yahoo! TV.
> >
> >  
> ---------------------------------------------------------------------- 
> --
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding  
> "site:https://lists.cs.wisc.edu/archive/gems-users/ " to your search.
> >
> >
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding  
> "site:https://lists.cs.wisc.edu/archive/gems-users/ " to your search.
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding  
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
--
Milo M. K. Martin (milom@xxxxxxxxxxxxx)
http://www.cis.upenn.edu/~milom/
Assistant Professor
Computer and Information Sciences Department
University of Pennsylvania