diff options
Diffstat (limited to 'TAO/orbsvcs/orbsvcs/Notify/Notify_ID_Pool_T.h')
-rw-r--r-- | TAO/orbsvcs/orbsvcs/Notify/Notify_ID_Pool_T.h | 51 |
1 files changed, 18 insertions, 33 deletions
diff --git a/TAO/orbsvcs/orbsvcs/Notify/Notify_ID_Pool_T.h b/TAO/orbsvcs/orbsvcs/Notify/Notify_ID_Pool_T.h index cc0c56e4a34..21b11a482b6 100644 --- a/TAO/orbsvcs/orbsvcs/Notify/Notify_ID_Pool_T.h +++ b/TAO/orbsvcs/orbsvcs/Notify/Notify_ID_Pool_T.h @@ -8,7 +8,7 @@ // Notify_ID_Pool_T.h // // = DESCRIPTION -// A class to generate ID's. +// A class to generate ID's and recycle them. // // = AUTHOR // Pradeep Gore <pradeep@cs.wustl.edu> @@ -18,12 +18,8 @@ #ifndef TAO_NOTIFY_ID_POOL_T_H #define TAO_NOTIFY_ID_POOL_T_H #include "ace/pre.h" -#include "ace/OS.h" - -#if !defined (ACE_LACKS_PRAGMA_ONCE) -# pragma once -#endif /* ACE_LACKS_PRAGMA_ONCE */ +#include "ace/OS.h" #include "ace/Containers_T.h" #include "orbsvcs/CosNotifyChannelAdminS.h" @@ -35,7 +31,10 @@ class TAO_Notify_ID_Pool // // = DESCRIPTION // This class is used by factories that need to associate id's with the - // objects that they create. + // objects that they create.When the objects are destroyed, these id's + // can be reused, hence the need to recycle. + // Using <get> several times in succession gives back the same id. + // Only when <next> is called, the current id is moved to the active_list_ // The very first id generated is always 0.The condition is necessary to // support ids for default objects that require an id of 0. // @@ -50,40 +49,26 @@ public: ID_TYPE get (void); // Returns the current id. + void put (ID_TYPE id); + // Put an ID back so that it might be recycled. + + void next (void); + // Generates the next id. + // The current id is moved to the active_list_. + protected: + ID_TYPE id_; + // The next available id. ID_TYPE max_id_; // This is the last id circulating in the list.When there are no more id's // in the resuse list, we increment this value to get a new id. - // @@ Pradeep: do you really need to do this? I mean, with a long - // or so you have 4 billion different IDs, recycling them is the - // least of your problems, right? - - // @@ Carlos: absolutely. I did not realize this. - // The recycling logic can be done away with! - - // Even if you need to recycle them, do you *really* need to keep - // *both* the active and free collections around? Isn't it enough - // to know which one is the maximum generated and the list of free - // ones? Anything else is active, right? - // Or if you know the active ones and the maximum given you know - // that anything else is free, right? - - // Carlos: right. with one list amd the max, the elements of the other list could be determined. - - // Also: in most cases the IDs will index some sort of map, right? - // You could obtain the active list from the set of keys in the map. - - // @@ Carlos: no, the <active_list_> list is the only list of id's. - // well, actually because i convert these ID's to ObjectID's and put them in POA's, - // i could get the list from the POA but there is no iterator in POA to get objectid's, - // - - // I guess it is a classical tradeoff between CPU and memory, but I - // would tend to conserve memory in this case... ACE_Unbounded_Set <ID_TYPE> active_list_; // List of ids currently in use by clients of this class. + + ACE_Unbounded_Set <ID_TYPE> reuse_list_; + // List of ids returned to this list and eligible to be used again. }; template <class ID_TYPE, class ID_TYPE_SEQ> |