I am trying to use POSIX named semaphore for cross-process synchronization. I noticed that after the process died or exit, the semaphore is still open by the system.
Is there anyway to make it closed/released after the process (which open it) die or exit?
An earlier discussion is here: How do I recover a semaphore when the process that decremented it to zero crashes?. They discussed several possible solutions there.
In short:
No. POSIX semaphores are not released if the owning process crashes or is killed by signals. The waiting process will have to wait forever. You can't work around this as long as you stick with semaphores.
You can use sockets or file locks to implement the inter-process synchronization, which can be released automatically when the process exits. The question owner I posted above eventually chose the file locks. See his answer. In the comment area, he posted a link to his blog that discusses this issue.
Other links that might help:
Why is sem_wait() not undone when my program crashes?: It also recommends file locks.
Is it possible to use mutex in multiprocessing case on Linux/UNIX ?: They discuss the use of mutex by sharing memory between processes for synchronization.
You seem to be having a conceptual problem with inter-process communication. An IPC mechanism's lifetime cannot be tied directly to the life cycle of any one process because then it could disappear out from under other processes accessing it. It is intentional that named semaphores persist until explicitly removed.
The Linux sem_overview(7) manual page, though not an authoritative specification, gives a run-down of semaphore life cycle management:
The sem_open(3) function creates a new named semaphore or opens an existing named semaphore. After the semaphore has been opened, it can be operated on using sem_post(3) and sem_wait(3). When a process has finished using the semaphore, it can use sem_close(3) to close the semaphore. When all processes have finished using the semaphore, it can be removed from the system using sem_unlink(3).
As the documentation for sem_unlink() makes clear, you can unlink a semaphore while processes still have it open. No processes can thereafter sem_open() that semaphore, and ultimately it will be cleaned up when the number of processes that have it open falls to zero. This is intentionally analogous to regular files.
If indeed there is one process that should be responsible for cleaning up a given named semaphore, then you should be sure that it sem_unlink()s it. Two reasonably good alternatives are to unlink it as soon as you are satisfied that all other processes that need it have opened it, or to register an exit handler that handles the unlinking. If viable, the former is probably better.
Related
In the POSIX thread interface, pthread_join(thread) can be used to block until the specified thread exits.
Is there a similar function that will allow execution to block until any child thread exits?
This would be similar to the wait() UNIX system call, except be applicable for child threads, not a processes
I don't think this is directly possible from pthreads per se, but you can work around it fairly easily.
Using the pthreads API, you can use pthread_cond_wait and friends to set up a "condition" and wait on it. When a thread is about to exit, signal the condition to wakeup the waiting thread.
Alternatively, another method is to create a pipe with pipe, and when a thread is going to exit, write to the pipe. Have the main thread waiting on the other end of the pipe with either select, poll, epoll, or your favorite variant thereof. (This also allows you to wait simultaneously on other FDs.)
Newer versions of Linux also include "eventfds" for doing the same thing, see man eventfd, but note this is only recently added. Note that is isn't POSIX, it's Linux-only, and it's only available if you're reasonably up-to-date. (2.6.22 or better.)
I've personally always wondered why this API wasn't designed to treat these things similar to file descriptors. If it were me, they'd be "eventables", and you could select files, threads, timers...
I don't think there's any function in the POSIX thread interface to do this.
You'd need to create your own version of it - e.g. an array of flags (one flag per thread) protected by a mutex and a condition variable; where just before "pthread_exit()" each thread acquires the mutex, sets its flag, then does "pthread_cond_signal()". The main thread waits for the signal, then checks the array of flags to determine which thread/s to join (there may be more than one thread to join by then).
You need to implement a customize one by pthread conditional variable: pthread_cond_wait(), pthread_cond_signal()/pthread_cond_broadcast().
I am trying to create a shared memory which will be used by multiple processes. these processes communicate with each other using MPI calls (MPI_Send, MPI_Recv).
I need a mechanism to control the access of this shared memory I added a question yesterday to see if MPI provides any facility to do that. Shared memory access control mechanism for processes created by MPI , but it seems that there is no such provision by MPI.
So I have to choose between named semaphore or flock.
For named semaphore if any of the process dies abruptly without calling sem_cloe(), than that semaphore always remains and can be seen by ll /dev/shm/. This results in deadlock sometimes(if I run the same code again!), for this reason I am currently thinking of using flock.
Just wanted to confirm if flock is best suited for this type of operation ?
Are there any disadvantages of using flock?
Is there anything else apart from named semaphore and flock that can be used here ?
I am working on C under linux.
You can also use a POSIX mutex in shared memory; you just have to set the "pshared" attribute on it first. See pthread_mutexattr_setpshared. This is arguably the most direct way to do what you want.
That said, you can also call sem_unlink on your named semaphore while you are still using it. This will remove it from the file system, but the underlying semaphore object will continue to exist until the last process calls sem_close on it (which happens automatically if the process exits or crashes).
I can think of two minor disadvantages to using flock. First, it is not POSIX, so it makes your code somewhat less portable, although I believe most Unixes implement it in practice. Second, it is implemented as a system call, so it will be slower. Both pthread_mutex_lock and sem_wait use the "futex" mechanism on Linux, which only does a system call when you actually have to wait. This is only a concern if you are grabbing and releasing the lock a lot.
I'm going to write a program in which the main thread creates new thread and then the new thread creates a child process. Since I have a hard time keeping track of the new thread and forked process, I'd like to gain a wise answer from someone.
My question is
1. Does a created process in a thread start to execute codes after pthread_create?
2. If 1 is not, where does the forked process start from if a call of fork in a thread occurs?
Thank you for reading my question.
Some of this is a bit OS-dependent, as different systems have different POSIX thread implementations and this can expose internals.
POSIX offers pthread_atfork as a somewhat blunt instrument for dealing with some of the issues, but it still looks pretty messy to me.
If your system uses a one-to-one map between "user land thread" and "kernel thread" using clone or rfork to achieve proper user-space sharing of data between threads, then fork will merely duplicate the (single) thread that calls it. However, if your system has a many-to-many style mapping (so that one user process is handling multiple threads, at least before they enter into blocking syscalls), fork may internally duplicate multiple threads. POSIX says it should look like it only duplicated one thread, so that's not supposed to be visible, but I'm not sure how well all systems implement this.
There's some general advice at http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them (Linux-centric, obviously, but still useful).
Is there some particular reason you want to fork inside a thread but not exec? In general, if you just want to run more code in parallel, you just spin off yet another thread (i.e., once you choose to run any threads, you do everything in threads, except if you have to fork for exec; if the exec fails, just _exit).
Is it possible to emulate the System V primitive semctl(semid,0,GETPID,0) in an environment using POSIX semaphores?
If it is not possible, I'm looking for a method to know who has done the last operation on a semaphore, I'm going to explain better...
I'm developing a UDP server with preforked children. The father handles SIGCHLD to respawn a dead child. If a child dies in the critical section (namely it has not yet done the sem_post) the father has to recognize this situation and unlock the semaphore.
I don't think it can be done. I don't see anything like this mentioned in the standard. Your best bet would be to ensure the application has no reason to die in a critical section.
You might think of attaching some state information to each semaphore ("who did the last DOWN on this semaphore?"). But then, if multiple processes are allowed to do a down on the semaphore (the semaphore starts with a value greater than 1) you will have to synchronize the way they are updating that information - back to square 1.
What you want cannot be done. You could emulate the behavior partly by writing your own semaphore based on POSIX robust mutexes (but it would have some disadvantages like not being async-signal-safe), or you could just use a robust mutex instead of a semaphore to begin with.
In the POSIX thread interface, pthread_join(thread) can be used to block until the specified thread exits.
Is there a similar function that will allow execution to block until any child thread exits?
This would be similar to the wait() UNIX system call, except be applicable for child threads, not a processes
I don't think this is directly possible from pthreads per se, but you can work around it fairly easily.
Using the pthreads API, you can use pthread_cond_wait and friends to set up a "condition" and wait on it. When a thread is about to exit, signal the condition to wakeup the waiting thread.
Alternatively, another method is to create a pipe with pipe, and when a thread is going to exit, write to the pipe. Have the main thread waiting on the other end of the pipe with either select, poll, epoll, or your favorite variant thereof. (This also allows you to wait simultaneously on other FDs.)
Newer versions of Linux also include "eventfds" for doing the same thing, see man eventfd, but note this is only recently added. Note that is isn't POSIX, it's Linux-only, and it's only available if you're reasonably up-to-date. (2.6.22 or better.)
I've personally always wondered why this API wasn't designed to treat these things similar to file descriptors. If it were me, they'd be "eventables", and you could select files, threads, timers...
I don't think there's any function in the POSIX thread interface to do this.
You'd need to create your own version of it - e.g. an array of flags (one flag per thread) protected by a mutex and a condition variable; where just before "pthread_exit()" each thread acquires the mutex, sets its flag, then does "pthread_cond_signal()". The main thread waits for the signal, then checks the array of flags to determine which thread/s to join (there may be more than one thread to join by then).
You need to implement a customize one by pthread conditional variable: pthread_cond_wait(), pthread_cond_signal()/pthread_cond_broadcast().