These mutexes currently can only be locked uniquely, there are no shared locking methods for it.
Step 1: Make mutex type configurable
eCAL memory files are protected by named mutexes. The goal is to make mutex types configurable through configuration.
CNamedMutex should define an enum, which underlying mutex type is used. We have (Windows) winapi_mutex, pthread_mutex, pthread_robust_mutex. Only the values that are supported on the platform are compiled in.
The eCAL configuration needs a member for shm global settings (e.g. like udp, tcp), which contain the configuration to use on the platform. these can be pthread_mutex or pthread_robust_mutex (linux) or winapi_mutex (windows).
The default value for linux shall be pthread_robust_mutex, for windows it will be winapi_mutex
eCAL Publisher and Subscriber individual configuration shall inherit the values from the global configuration.
Step 2
eCAL registration for topics shall contain the mutex type used for the transport layer as part of the transport layer information.
Step 3: Introduce system check in eCAL monitor (or dedicated tool)
The mutex type information needs to be propagated to eCAL Monitoring information
Since we could now potentially misconfigure eCAL, we need a tool that checks the configuration, e.g. checks that publishers / subscribers which want to communicate with each other actually use the same mutex types.
This check can be carried out in eCAL Monitor, along with the check about the monitoring information.
It makes sense to create a module, that can carry out certain checks, based on the eCAL monitoring information.
Step 4: Introduce CNamedSharedMutex / CNamedSharedMutexBase class that can be used as shared mutex. At the same time change usage in CMemoryFile to lock unique / shared based on mutex type.
Maybe also make it compatible with std::lock_guard / std::unique_lock / std::shared_lock usage.
Step 5: Implement CNamedSharedMutexLinux to provide a Linux Implementation
Linux primitives to be reused are available. They can be tricky with the clock types (not necessarily work with monotonic clock, only system clock....)
Step 5: Implement CNamedSharedMutexWindows to provide a Windows Implementation
Implementation strategy TBD
-> This provides a backwards compatible way to introduce new lock types and use shared read/write locks when performance mandates it.
Solves #670
These mutexes currently can only be locked uniquely, there are no shared locking methods for it.
Step 1: Make mutex type configurable
eCAL memory files are protected by named mutexes. The goal is to make mutex types configurable through configuration.
CNamedMutex should define an enum, which underlying mutex type is used. We have (Windows) winapi_mutex, pthread_mutex, pthread_robust_mutex. Only the values that are supported on the platform are compiled in.
The eCAL configuration needs a member for shm global settings (e.g. like udp, tcp), which contain the configuration to use on the platform. these can be pthread_mutex or pthread_robust_mutex (linux) or winapi_mutex (windows).
The default value for linux shall be pthread_robust_mutex, for windows it will be winapi_mutex
eCAL Publisher and Subscriber individual configuration shall inherit the values from the global configuration.
Step 2
eCAL registration for topics shall contain the mutex type used for the transport layer as part of the transport layer information.
Step 3: Introduce system check in eCAL monitor (or dedicated tool)
The mutex type information needs to be propagated to eCAL Monitoring information
Since we could now potentially misconfigure eCAL, we need a tool that checks the configuration, e.g. checks that publishers / subscribers which want to communicate with each other actually use the same mutex types.
This check can be carried out in eCAL Monitor, along with the check about the monitoring information.
It makes sense to create a module, that can carry out certain checks, based on the eCAL monitoring information.
Step 4: Introduce CNamedSharedMutex / CNamedSharedMutexBase class that can be used as shared mutex. At the same time change usage in CMemoryFile to lock unique / shared based on mutex type.
Maybe also make it compatible with std::lock_guard / std::unique_lock / std::shared_lock usage.
Step 5: Implement CNamedSharedMutexLinux to provide a Linux Implementation
Linux primitives to be reused are available. They can be tricky with the clock types (not necessarily work with monotonic clock, only system clock....)
Step 5: Implement CNamedSharedMutexWindows to provide a Windows Implementation
Implementation strategy TBD
-> This provides a backwards compatible way to introduce new lock types and use shared read/write locks when performance mandates it.
Solves #670