Is linux releasing a spinlock / semaphore when it kills a process?

It depends on the type of blocking you are talking about.

If you are talking about any internal kernel locks, they will be released as needed (as your system will soon crash otherwise). In general, such locks do not belong to the process itself, but rather to some internal kernel worker process, and usually do not remain locked after the process has returned to user space anyway.

Note, however, that if the kernel was already deadlocked when you performed the kill, chances are the process will not be killed. Killing a process is done as part of a signal path that is called from jump code to return the kernel to the user. If a process is waiting for a kernel spinlock, you will never go to return code, and therefore the process will not terminate.

Also, if a process is killed due to an OOPS kernel, then all bets are inactive - the kernel is already in an inconsistent state, and the OOPS exit code doesn't try very hard to clear any kernel thread locks might have been holding at this time.

If you are talking about any single spinlock or semaphore (including sem_*

the IPC family of semaphores), no, they will not be released since there is no concept of locking a property with a semaphore.

If you're talking about flock

file locks or file locks fcntl(F_SETLK, ...)

, they will be automatically released when any file descriptor associated with the file in this process is closed. Because of this, this flock

is a bad idea to use in most cases, but yes, it will be released if the process is killed.

If you are talking about a local pthread_mutex

process, this is up for debate because the mutex will cease to exist with the process.

If you are talking about a pthread_mutex

shared memory segment (in which pthread_mutexattr_setpshared

it is shared to create), it will only be auto-implemented if it is also marked as a trusted mutex pthread_mutexattr_setrobust

- but it should be marked as sequential reuse; See the pthread_mutex_consistent

manpage for details.