Hi,
I've created a simple pthread_mutex_lock wrapper to have a scoped lock like in boost::thread
Now , while I'm trying to re-write some code to make use of this, I'm stucking this this part:Code:// .h // ----- #ifndef SCOPEDLOCK_H #define SCOPEDLOCK_H #include "pthread.h" #include <boost/utility.hpp> class ScopedLock : boost::noncopyable { pthread_mutex_t& mrMutex; public: ScopedLock(pthread_mutex_t& _m); ~ScopedLock(); }; #endif //SCOPEDLOCK_H // .cpp // ----- #include "ScopedLock.h" ScopedLock::ScopedLock(pthread_mutex_t& _m) :mrMutex(_m) { pthread_mutex_lock(&mrMutex); } ScopedLock::~ScopedLock() { pthread_mutex_unlock(&mrMutex); }
As you see I'm creating a scope to lock mPrioQueueMutex inside. Then I'm constructing the smanager object, which I also need outside the scope.Code:[...] { ScopedLock sl(mPrioQueueMutex); boost::shared_ptr<SwarmManagerEntity> smanager(new SwarmManagerEntity( entity_id, *this, mrPrioQueue, PrioSet::DEFAULT_PRIO)); } // put it in the pointer container { pthread_mutex_lock(mLocalSwarmManagerMapMutex); mLocalSwarmManagerMap.insert( std::make_pair<int, boost::shared_ptr<SwarmManagerEntity> >(entity_id, smanager)); // copy the entity state from swrm to object smanager->update_from_Swrm(); } [...]
I see 2 possibilities:
- adding a SwarmManagerEntity default ctor together with an initialize member to do two-step-construction. Then the object could be created outside the scope and initialized inside the critical section.
Thats work...
or
- I could expand the critical section to the point the smanager object isn't needed any more.
Thats bad...
Is there another solution?
Thank you in advance!



LinkBack URL
About LinkBacks


