Bug 595815
Summary: | pthread_spin_lock() blocks instead of returning EDEADLK | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Geoff Levner <geoff> | ||||
Component: | glibc | Assignee: | Andreas Schwab <schwab> | ||||
Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-tools-bugs | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 5.5 | CC: | charlieb-fedora-bugzilla, fweimer | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-05-26 13:17:08 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
http://opengroup.org/onlinepubs/9699919799/functions/pthread_spin_lock.html The results are undefined if the calling thread holds the lock at the time the call is made. (In reply to comment #1) > http://opengroup.org/onlinepubs/9699919799/functions/pthread_spin_lock.html > > The results are undefined if the calling thread holds the lock at the time the > call is made. In that case, the man page is incorrect (according to Geoff's assertion - I haven't checked), and should be updated. Bug should be re-opened. (In reply to comment #2) The man page is ambiguous. It does indeed say that the results are undefined if the calling thread holds the lock at the time the call is made. But it also says, in the section on return codes, that pthread_spin_lock() may return EDEADLK if that is the case (which would be quite useful). |
Created attachment 416453 [details] test program illustrating the bug According to the man page, pthread_spin_lock() should fail and return EDEADLK if the given lock is already held by the calling thread. In fact it blocks. The bug can be reproduced using the attached test program.