JANA2
C++ framework for multi-threaded data processing
Loading...
Searching...
No Matches
JLockService Class Reference
Inheritance diagram for JLockService:
[legend]
Collaboration diagram for JLockService:
[legend]

Public Member Functions

pthread_rwlock_t * CreateLock (const std::string &name, bool throw_exception_if_exists=true)
 
pthread_rwlock_t * ReadLock (const std::string &name)
 
pthread_rwlock_t * WriteLock (const std::string &name)
 
pthread_rwlock_t * Unlock (const std::string &name=std::string("app"))
 
pthread_rwlock_t * RootReadLock ()
 
pthread_rwlock_t * RootWriteLock ()
 
pthread_rwlock_t * RootUnLock ()
 
pthread_rwlock_t * RootFillLock (JEventProcessor *proc)
 
pthread_rwlock_t * RootFillUnLock (JEventProcessor *proc)
 
pthread_rwlock_t * GetReadWriteLock (std::string &name)
 
pthread_rwlock_t * GetRootReadWriteLock ()
 
pthread_rwlock_t * GetRootFillLock (JEventProcessor *proc)
 
- Public Member Functions inherited from JService
virtual ~JService ()=default
 acquire_services is a callback which allows the user to configure a JService which relies on other JServices.
 
void DoInit (JServiceLocator *)
 
virtual void Init ()
 
virtual void acquire_services (JServiceLocator *)
 
- Public Member Functions inherited from jana::components::JComponent
void SetLevel (JEventLevel level)
 
void SetCallbackStyle (CallbackStyle style)
 
void SetPrefix (std::string prefix)
 
void SetTypeName (std::string type_name)
 For convenience, we provide a NAME_OF_THIS macro so that the user doesn't have to store the type name as a string, because that could get out of sync if automatic refactoring tools are used.
 
JApplicationGetApplication () const
 
JLoggerGetLogger ()
 
std::string GetPrefix () const
 
JEventLevel GetLevel () const
 
std::string GetLoggerName () const
 
std::string GetPluginName () const
 
void SetLoggerName (std::string logger_name)
 
void SetPluginName (std::string plugin_name)
 
std::string GetTypeName () const
 
virtual void Summarize (JComponentSummary &) const
 
CallbackStyle GetCallbackStyle () const
 
Status GetStatus () const
 
void SetApplication (JApplication *app)
 
void SetLogger (JLogger logger)
 
template<typename F >
void CallWithJExceptionWrapper (std::string func_name, F func)
 
void RegisterParameter (ParameterBase *parameter)
 
void RegisterService (ServiceBase *service)
 
const std::vector< ParameterBase * > GetAllParameters () const
 

Additional Inherited Members

- Public Types inherited from jana::components::JComponent
enum class  Status {
  Uninitialized ,
  Initialized ,
  Opened ,
  Closed ,
  Finalized
}
 
enum class  CallbackStyle {
  LegacyMode ,
  ExpertMode ,
  DeclarativeMode
}
 
- Protected Attributes inherited from jana::components::JComponent
std::vector< ParameterBase * > m_parameters
 
std::vector< ServiceBase * > m_services
 
JEventLevel m_level = JEventLevel::PhysicsEvent
 
CallbackStyle m_callback_style = CallbackStyle::LegacyMode
 
std::string m_prefix
 
std::string m_plugin_name
 
std::string m_logger_name
 
std::string m_type_name
 
Status m_status = Status::Uninitialized
 
std::mutex m_mutex
 
JApplicationm_app = nullptr
 
JLogger m_logger
 

Member Function Documentation

◆ ReadLock()

pthread_rwlock_t * JLockService::ReadLock ( const std::string &  name)
inline

Lock a global, named, rw_lock for reading. If a lock with that name does not exist, then create one and lock it for reading.

This is a little tricky. Access to the map of rw locks must itself be controlled by a rw lock. This means we incure the overhead of two locks and one unlock for every call to this method. Furthermore, to keep this efficient, we want to try only read locking the map at first. If we fail to find the requested lock in the map, we must release the map's read lock and try creating the new lock.

◆ RootFillLock()

pthread_rwlock_t * JLockService::RootFillLock ( JEventProcessor proc)
inline

Use this to lock a rwlock that is used exclusively by the given JEventProcessor. This addresses the common case where many plugins are in use and all contending for the same root lock. You should only use this when filling a histogram and not for creating. Use RootWriteLock and RootUnLock for that.

◆ RootFillUnLock()

pthread_rwlock_t * JLockService::RootFillUnLock ( JEventProcessor proc)
inline

Use this to unlock a rwlock that is used exclusively by the given JEventProcessor. This addresses the common case where many plugins are in use and all contending for the same root lock. You should only use this when filling a histogram and not for creating. Use RootWriteLock and RootUnLock for that.

◆ Unlock()

pthread_rwlock_t * JLockService::Unlock ( const std::string &  name = std::string("app"))
inline

Unlock a global, named rw_lock

◆ WriteLock()

pthread_rwlock_t * JLockService::WriteLock ( const std::string &  name)
inline

Lock a global, named, rw_lock for writing. If a lock with that name does not exist, then create one and lock it for writing.

This is a little tricky. Access to the map of rw locks must itself be controlled by a rw lock. This means we incure the overhead of two locks and one unlock for every call to this method. Furthermore, to keep this efficient, we want to try only read locking the map at first. If we fail to find the requested lock in the map, we must release the map's read lock and try creating the new lock.


The documentation for this class was generated from the following file: