ken@gvax.cs.cornell.edu (Ken Birman) (06/23/89)
I am trying to write some programs using the ISIS transaction facilities. I was going through the the Bank demo program and have some questions on "Queues." I have searched the manual, but couldn't find any mention on queues, their structure and how to work with them. For example, in the bank demo program, there are some functions such as "qu_null, qu_add.." Can you explain a little more on Queues, What their structure is? What are the different functions available?, etc. Also in the same Bank demo program, there is a variable type "adesc", which is used to declare "account_ad, and trans_ad". Could you throw some more light on this? Vshankar
ken@gvax.cs.cornell.edu (Ken Birman) (06/23/89)
> ... Can you explain a little more on Queues, What their > structure is? What are the different functions available?, etc. ISIS uses a simple queue mechanism quite heavily as part of the system. A queue is a double-linked list of nodes. Each node has a "name", a "flag", a "data field" and a "free routine". ISIS uses two kinds of "names" for nodes -- integers and addresses. The qu_xxx routines deal with integer names and the pg_xxx routines with addresses. You can append to a queue, delete a node (the free routine is applied to the data field, then the node is unlinked and put on a free list), search for a node, etc. See clib/cl_queues.[h,c] for details. The interface is quite simple, although we have many varients on the routines for different data types in the name and data fields. The code is the only documentation available, but since the routines are so simple nothing more is really needed. Anyhow, this stuff is really more for internal use within the clib than for application builders. > ... Also in the same Bank demo program, there is a variable type "adesc", > which is used to declare "account_ad, and trans_ad". Could you throw > some more light on this? ISIS has a dynamic memory allocator; source is in cl_alloc.c. To use it you need to describe the type of object being managed using an adesc data structure, which is initialized as follows adesc obj_ad ={ sizeof(obj), amount_to_zero, # to alloc at a time} ISIS will maintain a free list and this results in faster alloc/free times than when using malloc and free, assuming that you alloc and free the same size of object repeatedly. You alloc as in: (obj_t*)mallocate(&obj_ad) and free as in: mdeallocate(obj_ptr, &obj_ad) usually we use defines to hide this behind a nice interface. The reason our allocator runs very fast is that the normal malloc has no idea which sizes of objects get re-allocated frequently, so it can't maintain free lists. Our scheme is basically a sophisticated free-list based allocator. It runs on top of malloc and free but tries not to call them too often. All of the above is internal to ISIS; you can certainly use it if you like but are not at all required to do so. We use this very heavily and gain substantial performance benefits from doing so.