locks example will deadlock on macos, but not Linux
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- operating-systems
Research direction
Start by running cargo run --example locks on macOS and Linux, then inspect the locks example and the changes from PR #29. Trace the mutex and rwlock cases that recursively lock and identify the macOS-specific deadlock. Done means the example completes on macOS without changing its Linux behavior.
Written by the indexing model from the issue text.
Description
Running command cargo run --example locks on Linux will run through a number of mutex and rwlock tests,
and eventually return to the command line.
After applying #29, the locks example will now compile and run on macos, but will deadlock, and not finish.
(Note that changes in PR #29 should not alter Linux behavior)
On linux, running the locks example will go through all the mutex and rwlocks examples and return to the prompt without deadlocking.
_I believe, but have not confirmed the macos failure is due to recursive Mutex and RWLock locking.
Linux appears to better handle recursive mutexes than macos, at least for the pthread calls.
https://en.wikipedia.org/wiki/Reentrant_mutex
In fact!, there is a 10 year old discussion on Stack Overflow how some recursive mutex code works on Linux, FreeBSD and Solaris, but fails to work on MacOS.
This is what leads me to believe the recursive locking of the example causes the deadlock on macos.
The macos platform has a special type: NSRecursiveLock
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html
This type is suggested for recursive locking needs. (And is not used in this library, macos pthreads is used)
one solution to fix the example would be to avoid recursive locking on the macos platform
So, this library might work well for you on macos, and you are not doing recursive locking.
In the linked wiki article, some notable computer scientists recommend against avoiding recursive locking if possible.
- Dominant language
- Rust
- Stars
- 66
- Forks
- 20
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from elast0ny/raw_sync-rs
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
elast0ny/raw_sync-rs#39 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
elast0ny/raw_sync-rs#34 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
elast0ny/raw_sync-rs#28 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
elast0ny/raw_sync-rs#22 ·
-
Memory lossOpen
Difficulty 4/5 3-5 days Newbie friendliness 25/100
elast0ny/raw_sync-rs#20 ·
All issues in elast0ny/raw_sync-rs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
manuscript-lang/manuscript#1364 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
fable-compiler/Fable#5157 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
C-bug needs-triage O-UEFI T-libs
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
移动端宽屏适配Open
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day