SystemC/TLM (C++) sharing memory pool; static members, static methods, Singleton or? -

context: writing specific communication protocol used between tlm models (hw blocks described systemc , c++). tlm notion not important, note communication mimicked allocating objects, generic payloads (gps), passed between these c++ models of hw blocks.

aim: protocol, want provide memory manager should able efficiently handle gps; quite important since in 1 simulation lots of gps constructed, used , destroyed , can slow down things lot. goal create simple used others without efforts.

issues:

1. the first issue had in creating single shared pool blocks communicating protocol. thought creating static member in mm class, realized that:

   • static members require definition in cpp. makes mm class less intuitive use (with different people using this, forget so) , prefer avoid that.
   • depending on (and in which?) in cpp file static variable definition done, pool might not have wet parameters needed initialized (i.e., number of mm instances created).

2. the second issue similar first one. want count number of instances , instead of pool need create shared counter used pool initialize itself. again, wanted avoid static variable definitions in cpp file , guarantee order of initialization.

i have considered mainly:

• static members (discarded reasons above)
• singletons (discarded because don't need create whole class pool make visible others , single-instanced)
• static methods (the approaches picked , not far complete singleton)

this code produced (only relevant part included):

/** * helper class count class' number of instances. */ class counter { public:   // constructor   counter() : count(0) {}    //destructor   virtual ~counter() {}  private:   unsigned int count;  public:   unsigned int get_count() {return count;}   void incr_count() {count++;}   void decr_count() {count--;} };   template <unsigned int max = 1> class mm: public tlm::tlm_mm_interface { //////////////////////////////typedefs , enums///////////////////////////// public:   typedef tlm::tlm_generic_payload gp_t;  ///////////////////////////class (con/de)structor//////////////////////////// public:   // constructor   mm() {inst_count().incr_count();}    // copy constructor   mm(const mm&) {inst_count().incr_count();}    // destructor   virtual ~mm() {}  // no need decrease instance count in our case  ////////////////////////////////class methods//////////////////////////////// public:   // counter number of isntances.   static counter& inst_count() {     static counter cnt;     return cnt;   }    /* pattern makes sure that:   -- 1. pool created when first alloc appears   -- 2. instances of mm have been created (known instance sequence)   -- 3. 1 pool exists */   static boost::object_pool<gp_t>& get_pool() {     static boost::object_pool<gp_t> p(       mm<max>::inst_count().get_count() * max / 2, // creation size       mm<max>::inst_count().get_count() * max      // max size used     );     return p;   }    // allocate   virtual gp_t* allocate() {     //...     return gp;   }    // free generic payload , data_ptr   virtual void free(gp_t* gp) {      //...      get_pool().destroy(gp);   } } 

now, initiator block class header should have member:

mm m_mm; 

and initiator block class cpp should use like:

tlm_generic_payload* gp; gp = m_mm.allocate(); //... m_mm.free(gp); // in truth called gp->release()...                // ...not important here 

having electronic hw background, trying improve coding style, learn new approaches , optimize speed/memory allocation.

is there better way achieve this? in particular considering doubts:

• it seems me not optimal workaround encapsulate counter in class, put locally (but static) in static method , same pool.
• even though systemc "simulation kernel" single-threaded, need consider multithread case...i not sure relationship between 2 static methods safe thou independently should safe...with c++03 g++ adds code guarantee , c++11:

§6.7 [stmt.dcl] p4 if control enters declaration concurrently while variable being initialized, concurrent execution shall wait completion of initialization.

thanks in advance.