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
 JServices may require other JServices, which may be loaded out of order from different plugins.
 
void DoInit (JServiceLocator *)
 
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 ()
 
void Wire (JApplication *app)
 
bool IsEnabled () const
 
void SetEnabled (bool is_enabled)
 
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
 
void SetApplication (JApplication *app)
 
void SetLogger (JLogger logger)
 
template<typename F >
void CallWithJExceptionWrapper (std::string func_name, F func)
 
void DoInit ()
 
virtual void Init ()
 
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  CallbackStyle {
  LegacyMode ,
  ExpertMode
}
 
- 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
 
std::atomic_bool m_is_initialized {false}
 
std::atomic_bool m_is_finalized {false}
 
std::mutex m_mutex
 
JApplicationm_app = nullptr
 
JLogger m_logger
 
bool m_is_enabled = true
 

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: