I'm trying to write a piece of code that should not been executed simultaneously neither by threads of the same process, nor by different processes. In other words, I need global synchronization mechanism guarantees absolute mutual exclusion on GNU/Linux.
What strategies I've tried so far:
- Plain mutexes (
std::mutex, pthread mutexes, etc.). The problem is these primitives provide synchronization just between threads inside one process, not different.
- File locks (
fcntl). According to the mans, they provide locking between different processes, but threads of one process inherit locking and could not synchronized. Anyway I tried, it didn't help me.
- Kernel-level POSIX named semaphores(
sem_post), using them with init value 1 as mutexes. It seems synchronized both cases successfully, but the problem is - if process was killed while holding the semaphore, the semaphore itself becomes still alive because it has kernel persistence. As a result, when process is restarting it's waiting for the sem forever.
- I've read about Open file description locks (
F_OFD_SETLK...) since my last attempt. It seems they could help me (I didn't understand it completely). But they are available since kernel v.3.15, and I need to build my sources for kernel v. 3.10.
- Also I tried to combine plain mutexes to get per-thread synchronization with file locks to achieve per-process synchronization. For unknown reasons - it doesn't works (no deadlocks or something like that occurred - it just can't synchronize it completely and code seems to be executed simultaneously).
So the question is - what approach will be relevant for this task? Should I keep trying combining different combine different primitives or use any other - I'm stuck and have no ideas what to do next.
P.S. The reason why I didn't post any code example - it doesn't make some sense here( and also due to NDA ). In a few words - it's a bug ( causing SIGSEGV ) in a large product which includes multiple threads and processes often calling some CUDA runtime methods simultaneously.
Yep, it's absolutely CUDA related problem - but we've discovered that restricting parallel execution could be a temporary solution for it. As I said, the problem is in organizing global and safe mutual exclusion for threads and processes.