不一定，鲁棒互斥锁的这个返回有特别含义。如果原锁确实以PTHREAD_MUTEX_ROBUST建立，前一个持有线程在未解锁时终止，下一次加锁可以取得锁，同时用EOWNERDEAD通知新持有者：原持有者已不在，共享状态可能不一致。它不能按一般“非零就是完全没取得资源”的模板处理。
适用的是实际采用相应鲁棒属性的Linux线程程序。默认的普通属性与鲁棒属性行为不同，不能只从错误名称猜锁的创建方式。应由维护者核原属性、目标对象、加锁返回及线程结束记录，普通用户看到应用无响应时，不直接认定就是这个条件，也不据此诊断电脑硬件故障。
观察关键是取得锁之后的数据状态。若确认收到这项通知，维护者要按应用自己的恢复设计检查受保护的数据；不能因已经获得排他访问，就认为前一线程留下的更新一定完整。官方对pthread_mutex_consistent也明确说明，调用只是告知实现共享数据已恢复一致，真正恢复数据是应用的责任，不是函数替应用完成资料修复。
后续解锁顺序还可能影响可恢复性。手册指出，新持有者若在使状态一致之前直接解锁，之后加锁会遇到ENOTRECOVERABLE。这里说明的是设计风险，不让用户现场补调用或改状态来消掉错误。缺少共享数据含义、恢复依据和授权时，应保留原现场交软件方，不能把错误提示消失当成数据正确。
风险是错误分支把已持有的锁当成没持有，或者不核数据便宣布恢复，使后续线程接触不一致内容。下一步交接去敏的锁属性、返回和相关更新时序，不发送客户共享数据本身。云岩区台式电脑用户可拨400-877-9605，先说明Linux应用及是否有原软件维护方。电脑快修网提供信息展示和第三方维修对接，具体支持、地址和安排当次确认，锁状态与原资料结果仍需分别验收。