Menu
If a process holds some spinlocks or semaphores, and exit accidently(e.g., killed by linux), would linux release these locks correctly? If linux doesn't do this work, why?
740
Semaphore are held for a longer period of time. To access its control structure it uses spin lock. 7. In spinlock, a process is waiting for lock will keep the processor busy by continuously polling the lock.
Each process which wants to acquire a spinlock , must write a value which represents spinlock acquired state to this variable and write spinlock released state to the variable. If a process tries to execute code which is protected by a spinlock , it will be locked while a process which holds this lock will release it.
There are two ways to avoid this: Do not acquire the lock. In many situations it is possible to design data structures that do not require locking, e.g. by using per-thread or per-CPU data and disabling interrupts. Switch to a different thread while waiting.
A spinlock is a lock that operates by disabling scheduler and possibly interrupts (irqsave variant) on that particular core that the lock is acquired on. It is different from a mutex in that it disables scheduling so only your thread can run while spinlock is held.
It depends on the type of lock you're talking about.
If you're talking about any kind of kernel internal lock, they will be released as appropriate (as your system would soon crash otherwise). In general these kind of locks are not owned by the process itself, but rather by some internal kernel workflow, and usually don't remain locked after the process returns to userspace anyway.
Note, however, that if the kernel is already deadlocked when you issue the kill, chances are the process won't be killed. Process killing is performed as part of the signal handling path, which is invoked from the kernel-to-userspace return transition code. If the process is waiting for a kernel spinlock, you'll never make it to the return code and so the process won't exit.
Additionally, if the process is killed because of a kernel OOPS, then all bets are off - the kernel is already in an inconsistent state, and the OOPS exit code doesn't try very hard to clean up any locks the kernel thread may have been holding at the time.
If you're talking about any sort of userspace spinlock or semaphore (including the sem_* family of IPC semaphores), no, they will not be released, as there is no concept of lock ownership with a semaphore.
If you're talking about the flock family of file locks, or fcntl(F_SETLK, ...) advisory locks, they will be automatically released when any file descriptor bound to the file in that process is closed. Because of this, flock is a bad idea to use in most cases, but yes, it would be released if the process was killed.
If you're talking about a process-local pthread_mutex, it's moot because the mutex will cease to exist along with the process.
If you're talking about a shared pthread_mutex in a shared memory segment (one in which pthread_mutexattr_setpshared has been used to make it sharable), it will be autoreleased only if it is also marked as a robust mutex, with pthread_mutexattr_setrobust - but it must be marked consistent before re-use; see the pthread_mutex_consistent manpage for details.
138
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
