Would it be possible to implement a map method on (some of) the lock guards? There has been talks about it being unsound for some implementations of Mutex, particularly the one in the standard library, but there are ways to do it and it's a very useful feature. Do you think it would work with your particular implementation?

As far as I can see pthread_condattr_t and friends were introduced in version 0.2.15 of libc but parking_lot_core says it only depends on ^0.2. Because of this I got some "unresolved name" build errors when I tried to build parking_lot together with libc 0.2.12.

Seeing a compilation error of "this is an associated function, not a method" when trying to call upgrade() on a RwLockUpgradableReadGuard. I've narrowed this down to parking_lot version 0.6.0; version 0.5.5 compiles the below files with no error (just irrelevant warnings about unused vars).

Was this breakage intentional? If so, what's the ergonomic way of calling upgrade() now? Frankly I have no idea how to call this method with >=0.6.0; even the help note from rustc isn't working out for me (maybe I'm dumb though).

Repro rust source file:

extern crate parking_lot;

use parking_lot::RwLock;

fn main() {
    let lock = RwLock::new(());
    let guard1 = lock.upgradable_read();
    let x = guard1.upgrade();
}

Cargo.toml:

[package]
name = "rusty-playground"
version = "0.1.0"

[dependencies]
parking_lot = "=0.6.3"

Compilation error:

$ cargo build
   Compiling rusty-playground v0.1.0 (file:///home/valloric/repos/rusty-playground)
error[E0599]: no method named `upgrade` found for type `lock_api::rwlock::RwLockUpgradableReadGuard<'_, parking_lot::raw_rwlock::ParkingLotRwLock, ()>` in the current scope
 --> src/main.rs:8:20
  |
8 |     let x = guard1.upgrade();
  |             -------^^^^^^^
  |             |      |
  |             |      this is an associated function, not a method
  |             help: use associated function syntax instead: `lock_api::rwlock::RwLockUpgradableReadGuard<'_, parking_lot::raw_rwlock::ParkingLotRwLock, ()>::upgrade`
  |
  = note: found the following associated functions; to be used as methods, functions must have a `self` parameter
  = note: the candidate is defined in an impl for the type `lock_api::rwlock::RwLockUpgradableReadGuard<'_, _, _>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: Could not compile `rusty-playground`.

To learn more, run the command again with --verbose.

You spin a bit in https://github.com/Amanieu/parking_lot/blob/master/src/raw_mutex.rs#L149 .

Why not spin a bit in https://github.com/Amanieu/parking_lot/blob/master/core/src/thread_parker/linux.rs#L49 ?

Maybe I'm missing something but spinning in the parking_lot park should be more efficient than spinning on the address directly because each thread has its own local data that it would spin on.

I benchmarked it and a straightforward attempt seemed to make mutexes slightly faster.

https://doc.rust-lang.org/nightly/std/thread/struct.Thread.html#method.id

ThreadId is now available in the standard library

Thanks for your work on parking_lot, @Amanieu! Parity ethereum client uses this crate a lot. Unfortunately Rust type system doesn't protect us from deadlocks, so t would be very helpful if you could add support for Condvars in deadlock detection. Do you think it's possible? cc @arthurprs

Hi, I noticed that you have an optional dependency on owning_ref in order to implement StableAddress for your custom mutex guard types. Starting with version 0.3.3 of owning_ref, this trait has been refactored into a separate crate which only contains the trait. This way, you can implement the trait without pulling in the rest of owning_ref.

Hey, I get:
panicked at 'parking_lot requires either NT Keyed Events (WinXP+) or WaitOnAddress/WakeByAddress (Win8+)'
when using a library that depends on parking_lot's Mutex etc.

What exactly does this mean? Do I have to install something in particular?
Running Windows 7, 64bits.

Trying to build rustc on x86_64-unknown-linux-gnux32 fails due to an issue with parking_lot on this target with tv_nsec:

   Compiling parking_lot_core v0.2.9
error[E0308]: mismatched types
  --> /home/glaubitz/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.2.9/src/thread_parker/linux.rs:71:26
   |
71 |                 tv_nsec: diff.subsec_nanos() as libc::c_long,
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected i64, found i32
help: you can cast an `i32` to `i64`, which will sign-extend the source value
   |
71 |                 tv_nsec: (diff.subsec_nanos() as libc::c_long).into(),
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `parking_lot_core`.

Caused by:
  process didn't exit successfully: `/srv/glaubitz/rust/rust/build/bootstrap/debug/rustc --crate-name parking_lot_core /home/glaubitz/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.2.9/src/lib.rs --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 --cfg feature="nightly" -C metadata=981ff45ad39e36a6 -C extra-filename=-981ff45ad39e36a6 --out-dir /srv/glaubitz/rust/rust/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnux32/release/deps --target x86_64-unknown-linux-gnux32 -L dependency=/srv/glaubitz/rust/rust/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnux32/release/deps -L dependency=/srv/glaubitz/rust/rust/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps --extern libc=/srv/glaubitz/rust/rust/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnux32/release/deps/liblibc-c7b3face5395fe7c.rlib --extern rand=/srv/glaubitz/rust/rust/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnux32/release/deps/librand-053103d70fc6fed7.rlib --extern smallvec=/srv/glaubitz/rust/rust/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnux32/release/deps/libsmallvec-f17522e856c301a0.rlib --cap-lints allow` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed
thread 'main' panicked at 'command did not execute successfully: "/srv/glaubitz/rust/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnux32" "-j" "64" "--release" "--features" " jemalloc" "--manifest-path" "/srv/glaubitz/rust/rust/src/rustc/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101', bootstrap/compile.rs:1061:9

This is a result of tv_nsec not being of the C type long but actually __syscall_slong_t which is a result of the kernel interface on x32 being 64-bit while the system itself is 32-bit.

A possible workaround for this issue would be something like

#[cfg(all(target_arch = "x86_64", target_pointer_width = "32"))]
tv_nsec: diff.subsec_nanos() as i64,
#[cfg(not(all(target_arch = "x86_64", target_pointer_width = "32")))]
tv_nsec: diff.subsec_nanos() as libc::c_long,

See also: rust-lang/libc#812 and https://sourceware.org/bugzilla/show_bug.cgi?id=16437

CC @malbarbo
CC @jrtc27

Is there any interest in using WaitOnAddress / WakeByAddressSingle for Windows clients which support it (Windows 8+)?

I'm asking myself, if these are faster why aren't they in libstd? I think read something about platform limitations, but it's not really clear why the standard library has to use platform-specific types. I also saw other people wondering about this, might be worth adding it to the README.

This is a follow-up from #24, hopefully more explicit :)

So first, a disclaimer: I know literally nothing about the internals of parking_lot, and very little about mutexes.

What I'd be looking for is a way to have parking_lot mutexes play nicely with futures. What I mean by “play nicely” is:

• It should never block the whole thread, only a task on the thread pool
• It should return eg. a Future<Item = MutexGuard<'a, T>>

The second point can easily be implemented by wrapping try_lock, so that leaves the first point to handle.

My reflection on parking_lot internals (please tell me if it's wrong) is:

• There is a “low-level” layer, which puts a thread to sleep, wake up a thread, etc.
• Upon these building blocks, mutexes are built
• Upon mutexes, guards are built

Most of the complexity would stand in the second layer above.

What I'm thinking is that, if the first layer could be swapped with an async-friendly layer (that would put a task to sleep instead of the whole thread, wake up a task, etc.), then I think it would become possible to reuse the biggest part of the code, that is in how mutexes are built on top of these primitives.

A way to do that may be to parameterize all parking_lot types on a helper trait that provides said functions, and static-dispatch on it, with type aliases for more convenience.

Now, as stated above, I know nothing about the internals of parking_lot, so I may completely be wrong in my analysis. Feel free to tell it to me if so :)

So, what do you think about this idea of splitting away the low-level task handling from the mutex building?

From the docs of RwLock:

This lock uses a task-fair locking policy which avoids both reader and writer starvation. This means that readers trying to acquire the lock will block even if the lock is unlocked when there are writers waiting to acquire the lock. Because of this, attempts to recursively acquire a read lock within a single thread may result in a deadlock.

I’m looking into building an abstraction on top of parking_lot to protect many objects with a single RwLock<()>. In the expected access patterns, I believe that starvation won’t be a problem but the deadlock with recursive reader access might be. Is it possible to configure RwLock to tweak this behavior?

CC @bholley

Condvar currently has no Debug.

It would be interesting to have these as separated types.

At some point it'd be nice to restart the conversation about getting this crate into the stdlib, or at least the nursery, and I think that process would be expedited if people had a way of knowing how far this crate is from being considered stable. Is there a checklist of some kind somewhere?

Currently we have MutexGuard::unlock_fair(). It'd be quite convenient for me to instead have something like that:

let lock = Mutex::new_fair(()); 
let lock = Mutex::new((), /* fair: */ false);  // or

Which would allow the normal Drop to be fair or unfair.

A function like .upgrade().

Hi @Amanieu,

This issue is just to ping you about rr-debugger/rr#1883.

Basically we were hitting this in Servo, and I thought that other people that could be using rr to debug programs that use parking_lot would encounter this.

Basically, HLE makes rr break right now. Probably a runtime check for RUNNING_UNDER_RR is prohibitive (maybe under debug_assertions it isn't?). In any case, maybe a note in the Readme or similar could help someone.

Anyway, feel free to close this at any time, thanks!

-- Emilio

This is a logical continuation of #10. It looks like the MappableMutexGuard is implemented, but nothing is done for RwLock. We have a strong case for it: a map with data that needs to be either read or created and then read. Ideally, it would have the following implementation (roughly):

fn get_data(&self, key: Key) -> ReadGuard<Data> {
  // lock the map, but only deal with a particular entry
  let guard = self.lock.upgradable_read().map(|map| map.entry(key));
  // fast path for keys already filled up
  if let Entry::Occupied(e) = *guard {
    return *e;
  }
  // slow path to add a new value
  let data = create_heavy_state(key);
  let gw = guard.upgrade();
  gw.or_insert(data);
  // and return it
  gw.downgrade().or_insert_with(|| ureachable!())
}

The deadlock_detection feature is documented a bit indirectly via API docs of the core crate. The nightly feature is only discussed on the issue tracker.

If this summary correct, could you please document all features in the README and/or API docs, in a more conspicuous way?

See https://travis-ci.org/matthiasbeyer/imag/jobs/373182521#L694

For the lazy:

error[E0432]: unresolved import `std::sync::atomic::spin_loop_hint`
  --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/parking_lot_core-0.2.14/src/spinwait.rs:14:5
   |
14 | use std::sync::atomic::spin_loop_hint;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `spin_loop_hint` in `sync::atomic`

Once lacks Debug implementation, which is inconvenient.

It seems that parking_lot makes use of TLS vars, which subtly makes the primitives unusable in some cases of thread destructors, since the internal TLS variable has been dropped. Ideally, a secondary path should exist, taken if the TLS variable has been destroyed.

parking_lot contains a number of useful pieces that are relatively independent. The implementation of SpinWait for example could come in handy for a number of other projects. Any chance of these being split out into independent crates that are then used by parking_lot?

Hi,
I apologize in advance for a question which might seem basic:

The standard library Mutex type implements UnwindSafe + RefUnwindSafe:

impl<T: ?Sized> UnwindSafe for Mutex<T>
impl<T: ?Sized> RefUnwindSafe for Mutex<T>

However, the implementation in a parking_lot doesn't.

The understanding of both implementations currently a bit out of my depth, but would it be practical (or even possible, for that matter) to lift those restrictions (implement the traits) for parking_lot::Mutex?

I encountered this problem, when the library I was writing against bumped it's major API to require those trait bounds, and my code was already using the parking_lot.

A recent release of parking_lot_core increased the minimum required Rust version to 1.26. The commit was made ~3 months ago.

Would you mind documenting in the README what the policy is to increase the minimum required Rust version?

Poison detection can be very useful, especially for debug builds.

One possible implementation can share the backend already in place for deadlock detection (w/ minor modifications).

Something along those lines could work:

1. Check if the thread is panicking on each guard drop()
   2a. If so, register it in the wait graph (ex: mutex A waits for mutex A).
   2b. If so, leave the mutex/rwlock locked (not required I think)
2. Modify the cycle detection to account for such cases

Naturally, calling std::thread::panicking is probably not super cheap so this must go behind a feature flag as well.

Like the equivalent methods for Condvar, these would only block while trying to acquire the lock until the given timeout.

I was benchmarking parking lot against my own crate and found a lock up bug https://github.com/sstewartgallus/parkinglotbug

The benchmark uses parking lot to implement an event semaphore and then uses the event semaphore to implement a lock.

Run cargo bench to get a lockup.

My platform is a 2 core x86-64 Linux machine.

This PR bumped the required Rust version from 1.13 to 1.18. While I don't think that's a problem since many users have that version already, I think it's a good practice to bump the minor version instead of the patch version on such a release. Releasing just a patch version can break other Travis builds that assure a certain rustc version works.

Forgive me if this is just totally outside the scope of this crate, given that I'm not really sure what level of added complexity/overhead this feature would add, but it would be wonderful to be able to do a "select" operation on multiple synchronization primitives (or even just multiple of the same kind).

Currently when using the std::sync/pthread primitives whenever I run into a case where I just want to select on e.g. a condition variable and a mutex or two condition variables I have to stop and go back to the whiteboard and figure out another strategy. Being able to select would open up a large number of other strategies and make implementing all sorts of things easier.

I know it might be obvious for some, but for me I was a little bit disappointed when I found out:

  Compiling parking_lot v0.1.0
/home/jhasse/.cargo/registry/src/github.com-88ac128001ac3a9a/parking_lot-0.1.0/src/lib.rs:101:1: 101:66 error: #[feature] may not be used on the stable release channel
/home/jhasse/.cargo/registry/src/github.com-88ac128001ac3a9a/parking_lot-0.1.0/src/lib.rs:101 #![feature(extended_compare_and_swap, const_fn, integer_atomics)]
                                                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Maybe add a note in the README?

I have been using the mutex from parking_lot in a number of projects on Windows 10, with no trouble. In particular the fact that it is a fair mutex is extremely valuable to me. When I tried to compile and run my code on Windows 7 however, I ran in to some trouble.

Compilation was completed without any issue. At runtime however, I got the following error printed out in my logs:

2018-04-21 10:09:50.711026800 ERROR nbe - thread 'ble_writer_result' panicked at 'parking_lot requires either NT Keyed Events (WinXP+) or WaitOnAddress/WakeByAddress (Win8+)': C:\dir\src\github.com-1ecc6299db9ec823\parking_lot_core-0.2.10\src\thread_parker/windows/mod.rs:39
2018-04-21 10:09:50.711026800 ERROR nbe - thread 'ble_writer_result' panicked at 'parking_lot requires either NT Keyed Events (WinXP+) or WaitOnAddress/WakeByAddress (Win8+)': C:\dir\src\github.com-1ecc6299db9ec823\parking_lot_core-0.2.10\src\thread_parker/windows/mod.rs:39
2018-04-21 10:09:50.711026800 ERROR nbe - ble_writer_thread terminated with Err: Any

I would have thought the WinXP+ for NT Keyed Events would have implied that Windows 7 was covered by this.

I'm writing some unsafe code that manages raw pointers directly for perf and I really need to store a RW lock inside a larger data-structure. The parking_lot_core crate has useful primitives to build such a lock, but all what I really need is the RawRwLock type that's already in parking_lot. There's little point in me implementing it from scratch.

Could RawRwLock (and thus likely RawMutex) be exposed in the public API? This would make writing low-level data-structures with embedded locks much easier.

Types like ParkingLotRwLock are needed for the outside world in order to build any type safe primitives using lock_api generic interface. Any reason they are not public?

How hard would it be to detect deadlocks and other types of "runtime bugs" in debug mode?

I think that typically when you want a Once, you're calculating a value, as in the example in the documentation. I propose parking_lot make it safe to do so by wrapping the value in the Once as Mutex and such do. I think defaulting the parameter to () would mean this wouldn't be a breaking change.

(It'd be like the lazycell crate's AtomicLazyCell except that if thread A tries to fill the cell while thread B is already doing so, thread A will wait for thread B. lazycell returns an error in this case.)

I think this would almost make it possible to lose the unsafe in said example:

use parking_lot::{Once, ONCE_INIT};

static VAL: Once<usize> = ONCE_INIT;  // error here :-(

// This function will only call `expensive_computation` once, and will
// otherwise always return the value returned from the first invocation.
fn get_cached_val() -> usize { VAL.call_once(expensive_computation) }

fn expensive_computation() -> usize {
    // ...
}

except that I don't think there can be a ONCE_INIT that would work for all types. So to make this work as a static for types other than (), it'd either have to use const fns (unstable) or expose the inner workings of the type (and I guess that'd be back to unsafe anyway as there'd be an UnsafeCell). So for now, this would be beneficial for non-statics, potentially beneficial for nightly with statics, and no worse than before for stable rust with statics.

std::sync::MutexGuard has an unwrap function that returns the contents of the mutex mutably. The lack of this in parking_lot makes it hard to just test it as a drop-in replacement for std::sync::mutex.

Is there (or will there be) an ability in parking_lot to gather some stats about the effectiveness of locks? E.g. an average wait time, contention ratio, etc? This would assist us greatly in making decisions as to what to lock and how in gfx-rs/gfx#2229 .

It'd be nice to have a ticketed lock (similar to this crate) using parking lot. Or should ticketed_lock be rebased/forked to be on top of parking lot instead?

i am not directly depend on parking_lot, but latest minor release forces me to upgrade rust to 1.24
because of spin_loop_hint

i consider this change as major breaking change

I'm relatively new to Rust, mainly just using it to compile a program I need on an ARM device.

The program requires parking_lot which seems to cause the error:

   Compiling parking_lot v0.5.1
error[E0308]: mismatched types
   --> /home/rescue/.cargo/registry/src/github.com-1ecc6299db9ec823/mach_object-0.1.5/src/commands.rs:694:54
    |
694 |         unsafe { Ok(String::from(try!(CStr::from_ptr(buf.as_ptr() as *const i8).to_str()))) }
    |                                                      ^^^^^^^^^^^^^^^^^^^^^^^^^ expected u8, found i8
    |
    = note: expected type `*const u8`
               found type `*const i8`

   Compiling string_cache_codegen v0.4.0
error[E0308]: mismatched types
   --> /home/rescue/.cargo/registry/src/github.com-1ecc6299db9ec823/mach_object-0.1.5/src/commands.rs:889:54
    |
889 |         unsafe { Ok(String::from(try!(CStr::from_ptr(s.as_ptr() as *const i8).to_str()))) }
    |                                                      ^^^^^^^^^^^^^^^^^^^^^^^ expected u8, found i8
    |
    = note: expected type `*const u8`
               found type `*const i8`

error: aborting due to 2 previous errors

error: Could not compile `mach_object`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Now that Rust (nightly) has std::sync::atomic::hint_core_should_pause, parking_lot_core::SpinWait should probably use that function directly instead of using asm!("" ::: "memory" : "volatile") in cpu_relax. Probably won't make a difference in terms of performance (I assume they basically do the same thing), but may ease portability.

Currently RwLock::read_recursive() can be used to achieve the same effect, but clone is easier to use and doesn't require a reference to the underlying lock.

We seem to currently be using plain atomics in the implementation of RwLock and Mutex. However, if you have something like RwLock<Vec<T>>, there's no guarantee that a write to the vector will reach another thread when it acquires a read lock shortly thereafter; you need a memory fence for that.

On x86 this doesn't matter since it has a strongly ordered memory model, but on ARM or w/e it will.

cc @eddyb

From the commit history I couldn't figure out why parking-lot is still depending on rand 0.4 ( on crates.io ) but it is.

When you get time could you please release a new version for core that definitely has the rand bump?