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:

  1. Plain mutexes (std::mutex, pthread mutexes, etc.). The problem is these primitives provide synchronization just between threads inside one process, not different.
  2. File locks (lockf, 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.
  3. Kernel-level POSIX named semaphores(sem_open, sem_wait, 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.
  4. 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.
  5. 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.

closed as too broad by Kiwy, schily, Jeff Schaller, Jesse_b, slm Jul 25 '18 at 17:38

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Write a daemon with a job queue, then use it. – Ipor Sircer Jul 25 '18 at 14:27
  • @IporSircer unfortanately, this can't be done. The task is to temporary fix a bug without significant code changes ( i.e. ideal case is to find relevant kernel sync primitive ) – Uroboros Jul 25 '18 at 14:49
  • I don't see why using file locks with mutexes wouldn't resolve your problem. You say you tried it and it didn't work. Can you figure out why? – Andy Dalton Jul 25 '18 at 16:59