当持有 LOCK_SH lockf() 文件锁的进程收到 SIGKILL 时，文件是否会在等待进程返回之前变为 LOCK_EX 可锁定？

如何解决当持有 LOCK_SH lockf() 文件锁的进程收到 SIGKILL 时，文件是否会在等待进程返回之前变为 LOCK_EX 可锁定？

我有一种情况，一个进程通过执行 lockf(fd,LOCK_SH) 使用 Python 的 fcntl 模块锁定特定文件。我有另一个进程 SIGKILL 它，wait 使该进程死亡，然后或多或少立即 lockf(fd,LOCK_EX | LOCK_NB) 同一个文件。

像这样：

import os
import fcntl
import time
import sys
import signal

pid = os.fork()
if pid:
    time.sleep(1)
    os.kill(pid,signal.SIGKILL)
    os.waitpid(pid,0)
    fcntl.lockf(os.open(sys.argv[0],os.O_WRONLY),fcntl.LOCK_EX | fcntl.LOCK_NB)
else:
    fcntl.lockf(os.open(sys.argv[0],os.O_RDONLY),fcntl.LOCK_SH)
    time.sleep(1000)

该文件在一个普通的 ext4 本地文件系统上，所有进程都在同一台机器上，所以奇怪的文件系统上的坏锁实现在这里不是问题。

我想知道如果有足够的病态调度，理论上第二个锁是否有可能失败。

POSIX 是否保证当您等待并获取其退出代码时，进程确实已死亡并被掩埋？或者该流程的一些清理工作是否仍待处理？
POSIX 是否保证在进程死亡和它在死亡时持有的锁的解析之间进行任何排序之前发生？
当前 Linux 内核在命令进程终止和进程终止时文件解锁方面的实际行为是什么？