Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganise std::unstable::mutex to add an RAII unlocker to the mutex & replace LittleLock #12235

Closed
wants to merge 7 commits into from

Conversation

huonw
Copy link
Member

@huonw huonw commented Feb 13, 2014

  • adds a LockGuard type returned by .lock and .trylock that unlocks the mutex in the destructor
  • renames mutex::Mutex to StaticNativeMutex
  • adds a NativeMutex type with a destructor
  • removes LittleLock
  • adds #[must_use] to sync::mutex::Guard to remind people to use it

@flaper87
Copy link
Contributor

Could you add a test for lock_noguard too?

@alexcrichton
Copy link
Member

I feel like this should also rename unlock to unlock_noguard to explicitly say that you don't need to call unlock unless you called lock_noguard. I don't think it will be called in the common case.

Currently Mutex isn't quite a drop-in replacement for LittleLock because LittleLock implements Drop but Mutex does not. The changes you made from LittleLock => Mutex are sadly currently leaking their mutex.

To solve this, we could have Mutex and StaticMutex like with sync::mutex, which is a bit sad, but I'm not entirely sure what the answer would be otherwise.

@huonw
Copy link
Member Author

huonw commented Feb 14, 2014

The changes you made from LittleLock => Mutex are sadly currently leaking their mutex.

Whoops. I imagine Mutex doesn't have a destructor on purpose?

@sfackler
Copy link
Member

It allows for static mutexes (yay C libraries).

@nikomatsakis
Copy link
Contributor

This is not sound without the revised destructor rules, from what I can see. On phone so cannot look up the relevant issue.

@huonw
Copy link
Member Author

huonw commented Feb 15, 2014

@nikomatsakis I'm not sure I understand... this doesn't add or remove destructors from any types (but does add an entirely new type with a destructor).

@alexcrichton
Copy link
Member

This looks great to me, nice work!

r=me with comments fixed

@@ -65,7 +65,7 @@ pub struct GreenTask {
pool_id: uint,

// See the comments in the scheduler about why this is necessary
nasty_deschedule_lock: Mutex,
nasty_deschedule_lock: StaticNativeMutex,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While you're at it, can you make this a NativeMutex?

This automatically unlocks its lock when it goes out of scope, and
provides a safe(ish) method to call .wait.
This better reflects its purpose and design.
This obsoletes LittleLock, and so it is removed.
This helps people remember to save the return value to keep the mutex
locked as appropriate.
bors added a commit that referenced this pull request Feb 15, 2014
- adds a `LockGuard` type returned by `.lock` and `.trylock` that unlocks the mutex in the destructor
- renames `mutex::Mutex` to `StaticNativeMutex` 
- adds a `NativeMutex` type with a destructor
- removes `LittleLock`
- adds `#[must_use]` to `sync::mutex::Guard` to remind people to use it
@bors bors closed this Feb 16, 2014
@nikomatsakis
Copy link
Contributor

@huonw I think I was wrong, I believe it is ok so long as the fields of all types with an unsafe dtor are private, to prevent surprise mutations -- but it all makes me a bit nervous. We need to finish #8861 (and perhaps #6834), since this kind of ad-hoc rule breakery is hard to verify and a bit creepy.

@huonw huonw deleted the raii-lock branch January 13, 2016 01:04
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 8, 2024
Fix release year in CHANGELOG.md

Fixes a typo in rust-lang#12224

CC: `@xFrednet` `@Manishearth`

---

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants