I have two processes which access to the same physical memory(GPIO data addr).
So how can I have synchronized between these apps?
I understand that we have some kind of locking mechanism such as mutex and semaphore, so which method is the fastest?
Thank for your help,
-nm
Mutexes and semaphores are generally considered to be concurrency solutions in the same address space -- meaning that different parts of the same program will lock their access to a resource using one of these contraptions.
When you're dealing with separate processes, the standard way to do this on Linux is to create something in /var/lock, like /var/lock/myapp.lock, and place your PID followed by a newline in it. Then other processes will check for its existence, and if you're crafty check the PID to make sure it's still alive, too.
If you need real-time access to the area, skip the filesystem and the processes will have to communicate via IPC (LET_ME_KNOW_WHEN_DONE, OKAY_IM_DONE, you get the idea), or -- better -- write a process whose sole purpose is to read and write to the GPIO memory, and your other programs communicate with it via IPC (probably the best approach).
mutex means mutual exclusion -- a semaphore is just a variable used to determine if the resource is in use. In windows, there is a Mutex object that can be created to protect a shared resource.
The issue is what language are you using? What OS (I am assuming linux). Most languages provide support for multi-threading and mutual exclusion, and you should use the built-in constructs.
For example, using C on Linux, you might want to
include semaphore.h
and look up the calls for sem_init, sem_wait etc.
Related
From APUE
POSIX semaphores are available in two flavors: named and unnamed. They differ
in how they are created and destroyed, but otherwise work the same. Unnamed
semaphores exist in memory only and require that processes have access to the memory
to be able to use the semaphores. This means they can be used only by threads in the
same process or threads in different processes that have mapped the same memory
extent into their address spaces. Named semaphores, in contrast, are accessed by name
and can be used by threads in any processes that know their names.
Unnamed semaphores "can be used only by threads in the
same process or threads in different processes that have mapped the same memory
extent into their address spaces", because "Unnamed semaphores exist in memory only".
What is the reason that named semaphores are usable by threads in any processes that know their names?
Thanks.
From man page of sem_overview:
On Linux, named semaphores are created in a virtual file system,
normally mounted under /dev/shm, with names of the form sem.somename
So those are accessible for 'threads in any processes' similar way than normal files are.
pthread library may then map those files to memory.
You're thinking about this backwards. The question is: "if I need to synchronize use of a shared resource between teo unrelated processes, hiw do I do it?" And the answer is "you can give a semaphore a name, and then it's not restricted to use in processes which share memory."
Why is that even useful? Well, the use cases may not be common -- perhaps you've never run into one -- but they certainly exist. There are lots of resources which are shared between unrelated processes: databases, configuration files, serial ports, printer queues, and many more. You can mediate between shared uses of these resources with lock files, but it's clunky and you end up reinventing the wheel on every project. Semaphores, on the other hand, are easy to use and have well-defined documented semantics.
However, most uses of semaphores are indeed between related processes which share memory. And you wouldn't want to unnecessarily pay the overhead for maintaining a name in a filesystem.
So we end up with two kinds of semaphores: cheap low-overhead ones which serve the most frequent use cases, and heavier higher-overhead ones which can be used more generally. The nice thing is that the semantics and API are very similar, so you don't need to learn a whole new set of concepts when you start using named semaphores.
I read that mutex is a semaphore with value 1 (binary semaphore) used to enforce mutual exclusion.
I read this link
Semaphore vs. Monitors - what's the difference?
which says that monitor helps in achieving mutual exclusion.
Can someone tell me the difference between mutex and monitor as both help achieve the same thing (Mutual Exclusion)?
Since you haven't specified which OS or language/library you are talking about, let me answer in a generic way.
Conceptually they are the same. But usually they are implemented slightly differently
Monitor
Usually, the implementation of monitors is faster/light-weight, since it is designed for multi-threaded synchronization within the same process. Also, usually, it is provided by a framework/library itself (as opposed to requesting the OS).
Mutex
Usually, mutexes are provided by the OS kernel and libraries/frameworks simply provide an interface to invoke it. This makes them heavy-weight/slower, but they work across threads on different processes. OS might also provide features to access the mutex by name for easy sharing between instances of separate executables (as opposed to using a handle that can be used by fork only).
Monitor are different then Mutex but they can be considered similar in a sense that Monitor are build on top of Mutex. See depiction of monitor in an image at the bottom, for clarity.
Monitor is a synchronization construct that allows threads to have both mutual exclusion (using locks) and cooperation i.e. the ability to make threads wait for certain condition to be true (using wait-set).
In other words, along with data that implements a lock, every Java object is logically associated with data that implements a wait-set. Whereas locks help threads to work independently on shared data without interfering with one another, wait-sets help threads to cooperate with one another to work together towards a common goal e.g. all waiting threads will be moved to this wait-set and all will be notified once lock is released. This wait-set helps in building monitors with additional help of lock (mutex).
I you want, you can see my answer here, which may or may not be relevant to this question.
You can find another relevant discussion here
Semaphore vs. Monitors - what's the difference?
Unfortunately the textbook definitions does not always correspond to how different platforms and languages use the terms. So to get precise answers you have to specify the platform and context. But in general:
A mutex is a lock which can only be owned by a single thread at a time. The lock doesn't in itself protect anything, but code can check for ownership of a mutex to ensure that some section of code is only executed by a single thread at a time. If a thread wants to acquire a mutex lock the thread is blocked until it becomes available.
In Java terminology a monitor is a mutex lock which is implicitly associated with an object. When the synchronized keyword is applied to classes or methods an implicit mutex lock is created around the code, which ensures that only one thread at a time can execute it. This is called a monitor lock or just a monitor.
So in Java a monitor is not a specific object, rather any object has a monitor lock available which is invoked with the synchronized keyword.
The synchronized keyword can also be used on a block of code, in which case the object to lock on is explicit specified. Here it gets a bit weird because you can use the monitor of one object to lock access to another object.
In computer science textbooks you may meet a different kind of monitor, the Brinch-Hansen or Hoare-monitor, which is a class or module which is implicitly thread-safe (like a synchronized class in Java) and which have multiple conditions threads can wait/signal on. This is a higher-level concept than the Java monitor.
C#/.NET has monitors similar to Java, but also have a Mutex class in the standard library - which is different from the mutex lock used in the monitor. The monitor lock only exist inside a single process, while the Mutex-lock is machine wide. So a monitor lock is appropriate for making objects and data-structures thread safe, but not for providing system-wide exclusive access to say a file or device.
So bottom line: These terms can mean different things, so if you want a more specific answer you should specify a specific platform.
In Linux,
do all types of interprocess communication need system calls?
Types of interprocess communication are such as
Pipes
Signals
Message Queues
Semaphores
Shared Memory
Sockets
Do all types of interthread communication need system calls?
I would like to know if all interprocess communications and interthread communications involve switching from user mode to kernel mode so that the OS kernel will run to perform the communications? Since system calls all involve such switch, I asked if the communications need system calls.
For example, "Shared memory" can be used for both interprocess and interthread communcations, but i am not sure if it requires system calls or involvement of OS kernel to take over the cpu to perform something.
Thanks.
For interprocess communication I am pretty sure you cannot avoid system calls.
For interthread communication I cannot give you a definitive answer, but my educated guess would be "yes-and-no". You see, you can communicate between threads using thread-safe queues, and the only thing that a thread-safe queue needs in order to work is a lock. If a lock is unavailable at the moment that a thread wants to obtain it, then of course the system must be involved in order to put the thread in a waiting mode. But if the lock is available to obtain, then the thread should be able to proceed without the need for any system call.
That's what I would guess, and I would be quite disappointed to find out that things do not actually work this way, because that would mean that code which I have up until now been considering pretty innocent in fact has a tremendous additional hidden overhead.
Yes, every IPC was set by some syscalls(2).
It might happen that some IPC was set by a previous program (e.g. the program in the same process before execve), for example when running a pipeline like ls | ./yourprog it is the shell which has called pipe(2), not yourprog.
Since threads -in the same process- (by definition) share a common address space they can communicate using some shared data. However, they often need some syscall for synchronization (e.g. with mutexes), see e.g. futex(7) - because you want to avoid spinlocks (i.e. wasting CPU power for waiting). But in practice you should use pthreads(7)
In practice you cannot use shared memory (like shm_overview(7)) without synchronization (e.g. with semaphores, see sem_overview(7)). Notice that cache coherence is tricky and makes memory model sometimes non-intuitive (and processor specific).
At least, you do not need a system call for each read/write to shared memory. Setting up shared memory will for sure and synchronizing threads/processes will often involve system calls.
You could use flags in shared memory for synchronization, but note that read and write of flags may not be atomic actions.
(For example if you set up a location in shared memory to be 0 in the beginning and then check for it to be non-zero, while the other process sets it to non-zero when ready for something)
Almost all the code and tutorials that I have read online so far involve using mutexes and semaphores for synchronisation amongst threads. Can they be used to synchronise amongst processes?
I'd like to write code that looks like this:
void compute_and_print() {
// acquire mutex
// critical section
// release mutex
}
void main() {
int pid = fork();
if ( pid == 0 ) {
// do something
compute_and_print();
}
else {
// do something
compute_and_print();
}
}
Could someone point me towards similar code that does this?
I understand that different processes have different address spaces, but I wonder if the above would be different address spaces, however, wouldn't the mutex refer to the same kernel object?
Yes, it is possible. There are many ways to synchronize different processes. Perhaps the most popular solutions for mutual exclusion in this field are System V IPC semaphores and atomic operations on shared memory. I recommend you read chapter 5 of David A Ruslin's book called Interprocess Communication Mechanisms, or better yet - the whole book.
As for your second question, most modern operating systems on commodity hardware would place processes in different address spaces, though it is also possible for processes to share the same address space (see Virtual Memory, Memory Protection). Either way, if IPC mechanism is handled by the kernel, then two processes would refer to the same "kernel object", as you said. In cases where mutual exclusion is implemented (almost) without the kernel (like spin locks of some sort that use "shared memory"), both processes would refer to the same physical memory even though their virtual addresses for that memory might be different.
Hope it helps. Good Luck!
Just to be clear, POSIX (and linux) support two separate families of semaphores that have two different interfaces and methods of usage.
There is the older SysV semaphores consisting of semget, semop, semctl and (somewhat optionally) ftok.
The more modern "posix" semaphores consist of sem_open/sem_init, sem_wait, sem_post, sem_close and sem_unlink.
The setup/usage regimes and capabilities are different enough that it is worth familiarizing yourself with both to see what is better for your use case.
You can also use process shared mutexes from the pthreads package.
Sounds like you're looking for System V IPC You would probably use a semaphore to synchronize between processes.
Here is a nice introduction to Sys V IPC in Linux
You'll want named mutex/semaphore's. Take a look at this StackOverflow answer that describes some points. Here's an IBM describing the use of pthread_mutexattr_setname_np. One thing to note that named mutex's in Linux are not 100% portable (i.e. it MIGHT work on Ubuntu but NOT on CentOS, etc. etc.), so you'll need to be sure your platform supports it. If a named mutex is not available on your system, you could use named pipes with some wait conditions or even local sockets. As another answer points out is SysV IPC.
The biggest question you'll need to answer first is how 'cross-linux-platform' compatible do you want your app to be.
I was wondering whether it would ever make sense to use a mutex or semaphore when there is only one thread?.
Thanks for your help.
I design thread protection into my components because they are reusable and scalable components intended to work in any environment I can realistically anticipate. Many times they are initially used in a single thread environment. Often times the scope of the implementation expands to include more threads. Then I don't have to chase down resources to protect from the new access scenarios.
Mutex can make sense, since Mutex can be used for system wide sharing, instead of internal process-wide sharing. For example, you can use a Mutex to prevent an application from being started twice.
This may be a bit out there but lets say you are writing a recursive function and you want each level to register with a separate resource. This way you can keep the responsibility of cleaning up the resource in one place (The resource pool).
Sounds like a trick question. Technically, yes. A named mutex can be used to synch multiple processes containing a single thread in each.
You can use system-wide semaphores (and even mutexes) to do inter-process communication.
You can signal from a single-threaded process to another single-threaded process by acquire()/release()-ing on a named semaphore, for example.
In case the environment supports system interrupts it adds non-linear behaviour.
Semaphore can be used in order to sleep in main thread until interrupt triggers.