锁定两个进程而不是线程的自由/原子操作

Question

I am sharing some data across multiple processes by using shared memory; I use inter processes mutexes to achieve synchronization.

My question is the following: is it possible to use lock-free data structures AND/OR atomic operations to achieve faster synchronization without using mutexes between 2 processes?

If not do you know what is the main reason for this?

They are used only to synchronize threads of the same process. Are these concepts portable to processes as well? If they aren't do you know any faster method to share/synchronize data across processes?

Answer 1

Are these concepts portable to processes as well?

Yes, atomic operations are universal both for threads and processes, IIF the memory atomically used is shared.

Atomic operation is specific instruction of processor itself and in knows nothing about threads or processes, it is just All-or-nothing (indivisible) complex of actions (read; compare; store) with low-level hardware implementation.

So, you can setup shared memory between processes and put an atomic_t into it.

lock-free

Yes, if lock-free is implemented only with atomic. (It should)

data structures

You should check, that shared memory is mapped to the same address in both processes when it is used to store pointers (in data structures).

If the memory will be mapped to different address, pointers will be broken in another process. In this case you need to use relative addresses, and do simple memory translation.

inter processes mutexes

And I should say that glibc>2.4 (NPTL) uses futex combined with atomic operations for non-contended lock (for Process shared mutexes = inter process mutexes). So, you already use atomic operations in shared memory.

Answer 2

On x86 with NPTL, most of the synchronization primitives have as their fast path just a single interlocked operation with a full memory barrier. Since x86 platforms don't really have anything lighter than that, they are already about the best you can do. Unless the existing atomic operations do exactly what you need to do, there will be no performance boost to pay back the costs of using the semantically lighter primitive.