std: Rewrite the `sync` module #19274

Merged
merged 2 commits into from Dec 5, 2014

Conversation

Projects
None yet
6 participants
@alexcrichton
Member

alexcrichton commented Nov 24, 2014

This commit is a reimplementation of std::sync to be based on the
system-provided primitives wherever possible. The previous implementation was
fundamentally built on top of channels, and as part of the runtime reform it has
become clear that this is not the level of abstraction that the standard level
should be providing. This rewrite aims to provide as thin of a shim as possible
on top of the system primitives in order to make them safe.

The overall interface of the std::sync module has in general not changed, but
there are a few important distinctions, highlighted below:

  • The condition variable type, Condvar, has been separated out of a Mutex.
    A condition variable is now an entirely separate type. This separation
    benefits users who only use one mutex, and provides a clearer distinction of
    who's responsible for managing condition variables (the application).

  • All of Condvar, Mutex, and RWLock are now directly built on top of
    system primitives rather than using a custom implementation. The Once,
    Barrier, and Semaphore types are still built upon these abstractions of
    the system primitives.

  • The Condvar, Mutex, and RWLock types all have a new static type and
    constant initializer corresponding to them. These are provided primarily for C
    FFI interoperation, but are often useful to otherwise simply have a global
    lock. The types, however, will leak memory unless destroy() is called on
    them, which is clearly documented.

  • The fundamental architecture of this design is to provide two separate layers.
    The first layer is that exposed by sys_common which is a cross-platform
    bare-metal abstraction of the system synchronization primitives. No attempt is
    made at making this layer safe, and it is quite unsafe to use! It is currently
    not exported as part of the API of the standard library, but the stabilization
    of the sys module will ensure that these will be exposed in time. The
    purpose of this layer is to provide the core cross-platform abstractions if
    necessary to implementors.

    The second layer is the layer provided by std::sync which is intended to be
    the thinnest possible layer on top of sys_common which is entirely safe to
    use. There are a few concerns which need to be addressed when making these
    system primitives safe:

    • Once used, the OS primitives can never be moved. This means that they
      essentially need to have a stable address. The static primitives use
      &'static self to enforce this, and the non-static primitives all use a
      Box to provide this guarantee.
    • Poisoning is leveraged to ensure that invalid data is not accessible from
      other tasks after one has panicked.

    In addition to these overall blanket safety limitations, each primitive has a
    few restrictions of its own:

    • Mutexes and rwlocks can only be unlocked from the same thread that they
      were locked by. This is achieved through RAII lock guards which cannot be
      sent across threads.
    • Mutexes and rwlocks can only be unlocked if they were previously locked.
      This is achieved by not exposing an unlocking method.
    • A condition variable can only be waited on with a locked mutex. This is
      achieved by requiring a MutexGuard in the wait() method.
    • A condition variable cannot be used concurrently with more than one mutex.
      This is guaranteed by dynamically binding a condition variable to
      precisely one mutex for its entire lifecycle. This restriction may be able
      to be relaxed in the future (a mutex is unbound when no threads are
      waiting on the condvar), but for now it is sufficient to guarantee safety.
  • Condvars support timeouts for their blocking operations. The
    implementation for these operations is provided by the system.

Due to the modification of the Condvar API, removal of the std::sync::mutex
API, and reimplementation, this is a breaking change. Most code should be fairly
easy to port using the examples in the documentation of these primitives.

[breaking-change]

Closes #17094
Closes #18003

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Nov 24, 2014

Collaborator

warning Warning warning

  • These commits modify unsafe code. Please review it carefully!
Collaborator

rust-highfive commented Nov 24, 2014

warning Warning warning

  • These commits modify unsafe code. Please review it carefully!
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 24, 2014

Member

Note that this is duplicating a lot of implementation details of librustrt and libsync as of this red hot minute. Once these two libs are merged into std I'll delete all the duplication and make sure that we've only got one copy of the definitions. This PR is meant to reflect the final state of the stdlib for std::sync and its implementation details.

Member

alexcrichton commented Nov 24, 2014

Note that this is duplicating a lot of implementation details of librustrt and libsync as of this red hot minute. Once these two libs are merged into std I'll delete all the duplication and make sure that we've only got one copy of the definitions. This PR is meant to reflect the final state of the stdlib for std::sync and its implementation details.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Nov 24, 2014

Member

Condvars and RWLocks now support timeouts for their blocking operations. The
implementation for these operations is provided by the system.

Woo!

Member

sfackler commented Nov 24, 2014

Condvars and RWLocks now support timeouts for their blocking operations. The
implementation for these operations is provided by the system.

Woo!

src/libstd/sync/condvar.rs
+ /// specified duration.
+ ///
+ /// The semantics of this function are equivalent to `wait()` except that
+ /// the thread will be blocked for no longer than `dur`. If the wait timed

This comment has been minimized.

@sfackler

sfackler Nov 24, 2014

Member

Might want to qualify this a bit - it's not really possible in general to unblock the thread after exactly the right duration.

@sfackler

sfackler Nov 24, 2014

Member

Might want to qualify this a bit - it's not really possible in general to unblock the thread after exactly the right duration.

src/libstd/sync/one.rs
@@ -0,0 +1,167 @@
+// Copyright 2014 The Rust Project Developers. See the COPYRIGHT

This comment has been minimized.

@sfackler

sfackler Nov 24, 2014

Member

Should this be one.rs or once.rs?

@sfackler

sfackler Nov 24, 2014

Member

Should this be one.rs or once.rs?

This comment has been minimized.

@alexcrichton

alexcrichton Nov 24, 2014

Member

Oh yay! I thought once was still a keyword. Looks like it is no longer a keyword.

@alexcrichton

alexcrichton Nov 24, 2014

Member

Oh yay! I thought once was still a keyword. Looks like it is no longer a keyword.

src/libstd/sync/rwlock.rs
+/// The type parameter `T` represents the data that this lock protects. It is
+/// required that `T` satisfies `Send` to be shared across tasks and `Sync` to
+/// allow concurrent access through readers. The RAII guards returned from the
+/// locking methods implement `Deref` (and `Deref` mut for the `write` methods)

This comment has been minimized.

@sfackler

sfackler Nov 24, 2014

Member

DerefMut, not Deref mut

@sfackler

sfackler Nov 24, 2014

Member

DerefMut, not Deref mut

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Nov 24, 2014

Member

I didn't see any timeout stuff in the RWLock impl, btw

Member

sfackler commented Nov 24, 2014

I didn't see any timeout stuff in the RWLock impl, btw

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 24, 2014

Member

Ah yes sorry, I mis-remembered what was added to rwlocks. RWLocks now support try_read and try_write, not timeouts just yet. I'd like to provide a unix extension trait to provide these functions, but Windows at least does not implement locking with a timeout.

Member

alexcrichton commented Nov 24, 2014

Ah yes sorry, I mis-remembered what was added to rwlocks. RWLocks now support try_read and try_write, not timeouts just yet. I'd like to provide a unix extension trait to provide these functions, but Windows at least does not implement locking with a timeout.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 25, 2014

Member

One thing I also just remembered, this removes the ability to use a condition variable with a RWLock for now. We can build something such as C++'s condition_variable_any in the future, but this PR is just aimed at exposing the system primitives for now.

Member

alexcrichton commented Nov 25, 2014

One thing I also just remembered, this removes the ability to use a condition variable with a RWLock for now. We can build something such as C++'s condition_variable_any in the future, but this PR is just aimed at exposing the system primitives for now.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 25, 2014

Member

Now that #19255 has merged I've rebased on top and removed all implementations of primitives based on channels. At the same time I have also remove all concurrent queues from the public interface as I don't think we're going to be able to stabilize them before 1.0. Two are kept as implementation details of channels, but the chase-lev deque and mpmc queue have been entirely removed.

Member

alexcrichton commented Nov 25, 2014

Now that #19255 has merged I've rebased on top and removed all implementations of primitives based on channels. At the same time I have also remove all concurrent queues from the public interface as I don't think we're going to be able to stabilize them before 1.0. Two are kept as implementation details of channels, but the chase-lev deque and mpmc queue have been entirely removed.

+ // We need a while loop to guard against spurious wakeups.
+ // http://en.wikipedia.org/wiki/Spurious_wakeup
+ while local_gen == lock.generation_id &&
+ lock.count < self.num_threads {

This comment has been minimized.

@aturon

aturon Nov 25, 2014

Member

Why is this second comparison needed?

@aturon

aturon Nov 25, 2014

Member

Why is this second comparison needed?

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

This is mostly just copy-pasted from the existing implementation, but I believe the first comparison is to determine whether this was the final thread (the notifier) or a thread which needs to wait. The second comparison is redundant the first iteration of the loop, but all other iterations it's intended to help with spurious wakeups.

@alexcrichton

alexcrichton Nov 26, 2014

Member

This is mostly just copy-pasted from the existing implementation, but I believe the first comparison is to determine whether this was the final thread (the notifier) or a thread which needs to wait. The second comparison is redundant the first iteration of the loop, but all other iterations it's intended to help with spurious wakeups.

+ let (tx, rx) = channel();
+
+ for _ in range(0u, 9) {
+ let c = barrier.clone();

This comment has been minimized.

@aturon

aturon Nov 25, 2014

Member

Does this actually work? Aren't you missing #[deriving(Clone)] on Barrier?

@aturon

aturon Nov 25, 2014

Member

Does this actually work? Aren't you missing #[deriving(Clone)] on Barrier?

This comment has been minimized.

@sfackler

sfackler Nov 25, 2014

Member

@aturon Barrier isn't Clone, but barrier is an Arc<Barrier> which is.

@sfackler

sfackler Nov 25, 2014

Member

@aturon Barrier isn't Clone, but barrier is an Arc<Barrier> which is.

This comment has been minimized.

@aturon

aturon Nov 25, 2014

Member

I can read, I swear!

@aturon

aturon Nov 25, 2014

Member

I can read, I swear!

src/libstd/sync/barrier.rs
+ }
+ }
+
+ /// Block the current thread until all tasks has rendezvoused here.

This comment has been minimized.

@aturon

aturon Nov 25, 2014

Member

"tasks have"

@aturon

aturon Nov 25, 2014

Member

"tasks have"

src/libstd/sync/condvar.rs
+/// variables: each condvar can be used with precisely one mutex at runtime. Any
+/// attempt to use multiple mutexes on the same condition variable will result
+/// in a runtime panic. If this is not desired, then the unsafe primitives in
+/// `sys` do not have this restriction.

This comment has been minimized.

@aturon

aturon Nov 25, 2014

Member

But isn't there UB on at least some systems if you do this?

@aturon

aturon Nov 25, 2014

Member

But isn't there UB on at least some systems if you do this?

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

Oh, right, it was UB to do so concurrently.

@aturon

aturon Nov 26, 2014

Member

Oh, right, it was UB to do so concurrently.

+
+/// Statically allocated condition variables.
+///
+/// This structure is identical to `Condvar` except that it is suitable for use

This comment has been minimized.

@aturon

aturon Nov 25, 2014

Member

This duplication is somewhat unfortunate :-/

@aturon

aturon Nov 25, 2014

Member

This duplication is somewhat unfortunate :-/

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

Yeah I'm not a big fan of it, but I think that for now the functionality win may be worth it. I would be totally ok stabilizing the non-static halves before the static halves.

@alexcrichton

alexcrichton Nov 26, 2014

Member

Yeah I'm not a big fan of it, but I think that for now the functionality win may be worth it. I would be totally ok stabilizing the non-static halves before the static halves.

src/libstd/sync/condvar.rs
+ /// specified duration.
+ ///
+ /// See `Condvar::wait_timeout`.
+ pub fn wait_timeout<T: AsMutexGuard>(&self, mutex_guard: &T,

This comment has been minimized.

@aturon

aturon Nov 25, 2014

Member

Did you want &'static self?

@aturon

aturon Nov 25, 2014

Member

Did you want &'static self?

This comment has been minimized.

src/libstd/sync/condvar.rs
+
+ fn verify(&self, mutex: &sys_mutex::Mutex) {
+ let addr = mutex as *const _ as uint;
+ if self.mutex.load(atomic::SeqCst) != addr {

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

I believe there's a race here. Suppose you have a mutex and a condvar shared by two threads.

The two threads both call verify concurrenty on the condvar for the same mutex.

  • The first thread passes the initial if, since the self.mutex is initially 0.
  • The second thread passes the initial if, since the self.mutex is initially 0.
  • The first thread successfully CASes
  • The second thread attempts to CAS, but fails -- but only because the address was already set to the correct one!

I think this can be fixed by dropping the initial load and instead always doing a CAS, and succeeded if the old address was either 0 or the correct address.

@aturon

aturon Nov 26, 2014

Member

I believe there's a race here. Suppose you have a mutex and a condvar shared by two threads.

The two threads both call verify concurrenty on the condvar for the same mutex.

  • The first thread passes the initial if, since the self.mutex is initially 0.
  • The second thread passes the initial if, since the self.mutex is initially 0.
  • The first thread successfully CASes
  • The second thread attempts to CAS, but fails -- but only because the address was already set to the correct one!

I think this can be fixed by dropping the initial load and instead always doing a CAS, and succeeded if the old address was either 0 or the correct address.

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

Or you could leave the initial load and just check the address after the CAS as suggested above.

If you do that, the initial load can be marked as Relaxed.

@aturon

aturon Nov 26, 2014

Member

Or you could leave the initial load and just check the address after the CAS as suggested above.

If you do that, the initial load can be marked as Relaxed.

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

Oh good catch! I'll remove the initial load as this is only done on wait anyway which isn't super performance sensitive. It's more straightforward to assume everyone gets past the optimistic check anyway (would have caught this quite quickly)

@alexcrichton

alexcrichton Nov 26, 2014

Member

Oh good catch! I'll remove the initial load as this is only done on wait anyway which isn't super performance sensitive. It's more straightforward to assume everyone gets past the optimistic check anyway (would have caught this quite quickly)

src/libstd/sync/condvar.rs
+ let _g = M.lock();
+ C.notify_all();
+ });
+ C.wait(&g);

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

Might be worth having a test of notify_all involving multiple concurrent waits.

Also, have you confirmed that on all platforms, notification prior to waits will still cause those waits to be woken? The expected behavior here should probably be documented for this module.

@aturon

aturon Nov 26, 2014

Member

Might be worth having a test of notify_all involving multiple concurrent waits.

Also, have you confirmed that on all platforms, notification prior to waits will still cause those waits to be woken? The expected behavior here should probably be documented for this module.

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

Do you mean the other way around? I was unaware of condition variables that buffered calls to notify_one or notify_all. I know posix at least doesn't do anything on the notification methods of there's no blockers, and it looks like Windows is sparsely documented in this topic, but I'm fairly certain that they operate the same way as posix.

@alexcrichton

alexcrichton Nov 26, 2014

Member

Do you mean the other way around? I was unaware of condition variables that buffered calls to notify_one or notify_all. I know posix at least doesn't do anything on the notification methods of there's no blockers, and it looks like Windows is sparsely documented in this topic, but I'm fairly certain that they operate the same way as posix.

@@ -1,828 +0,0 @@
-// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

Wheeeee!

@aturon

aturon Nov 26, 2014

Member

Wheeeee!

src/libstd/sync/mutex.rs
+use cell::UnsafeCell;
+use kinds::marker;
+use sync::{poison, AsMutexGuard};
+use sys_common::mutex as sys;
/// A mutual exclusion primitive useful for protecting shared data
///
/// This mutex will properly block tasks waiting for the lock to become

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

What does "properly block" mean?

@aturon

aturon Nov 26, 2014

Member

What does "properly block" mean?

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

It means I forgot to reword this documentation.

@alexcrichton

alexcrichton Nov 26, 2014

Member

It means I forgot to reword this documentation.

src/libstd/sync/mutex.rs
-/// `new` constructor.
+/// `new` constructor. Each mutex has a type parameter which represents the data
+/// that it is protecting. The data can only be accessed through the RAII guards
+/// returned from `lock` and `try_lock`.

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

Probably worth elaborating: "meaning that the data is guaranteed to be accessed only when the lock is held."

@aturon

aturon Nov 26, 2014

Member

Probably worth elaborating: "meaning that the data is guaranteed to be accessed only when the lock is held."

src/libstd/sync/mutex.rs
///
-/// let m = Mutex::new();
+/// let m = Mutex::new(4u);

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

This example could be... a little more exciting.

@aturon

aturon Nov 26, 2014

Member

This example could be... a little more exciting.

#[must_use]
-pub struct Guard<'a> {
- guard: mutex::LockGuard<'a>,
+pub struct MutexGuard<'a, T: 'a> {

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

This should just be Guard here (see rust-lang/rfcs#356) and renamed on re-export.

@aturon

aturon Nov 26, 2014

Member

This should just be Guard here (see rust-lang/rfcs#356) and renamed on re-export.

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

I originally did that, but this is only exported as MutexGuard (code can't access std::sync::mutex), and the documentation presents itself a little nicer if it's not renamed. Right now rustdoc will not rename all uses of Guard in this module, despite Guard being exported under a different name.

@alexcrichton

alexcrichton Nov 26, 2014

Member

I originally did that, but this is only exported as MutexGuard (code can't access std::sync::mutex), and the documentation presents itself a little nicer if it's not renamed. Right now rustdoc will not rename all uses of Guard in this module, despite Guard being exported under a different name.

+///
+/// Note that this trait should likely not be implemented manually unless you
+/// really know what you're doing.
+pub trait AsMutexGuard {

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

I'd like to get rid of this, but probably we can get away with making it #[experimental] for 1.0, which would prevent new implementations/uses of it, but should allow the rest of the API to work just fine.

@aturon

aturon Nov 26, 2014

Member

I'd like to get rid of this, but probably we can get away with making it #[experimental] for 1.0, which would prevent new implementations/uses of it, but should allow the rest of the API to work just fine.

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

I agree, the only reason for its current existence is to allow interoperation between static/non-static cvars/mutexes, I'm.. not a big fan of it though. If we could get rid of StaticMutex then this could just take MutexGuard.

@alexcrichton

alexcrichton Nov 26, 2014

Member

I agree, the only reason for its current existence is to allow interoperation between static/non-static cvars/mutexes, I'm.. not a big fan of it though. If we could get rid of StaticMutex then this could just take MutexGuard.

src/libstd/sync/poison.rs
+
+use task::failing;
+
+pub struct Flag { pub failed: bool }

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

panicked?

@aturon

aturon Nov 26, 2014

Member

panicked?

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Nov 26, 2014

Member

I've done a partial review; I still need to look at rwlock, semaphore, and the sys stuff.

Member

aturon commented Nov 26, 2014

I've done a partial review; I still need to look at rwlock, semaphore, and the sys stuff.

+ let g = M.lock();
+ spawn(proc() {
+ let _g = M.lock();
+ C.notify_one();

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

This test is racy given that notifications aren't buffered. (The spawned thread could complete the notification before the parent thread waits.)

Also, still think it's worth specifying the behavior wrt buffering. Park/unpark, for example, do buffer wakeups (to some degree).

@aturon

aturon Nov 26, 2014

Member

This test is racy given that notifications aren't buffered. (The spawned thread could complete the notification before the parent thread waits.)

Also, still think it's worth specifying the behavior wrt buffering. Park/unpark, for example, do buffer wakeups (to some degree).

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

If I were to say that the lock was acquired before the thread was spawned to prevent the race, would that change your opinion? I'll be sure to make sure the documentation is quite stern about this though :)

@alexcrichton

alexcrichton Nov 26, 2014

Member

If I were to say that the lock was acquired before the thread was spawned to prevent the race, would that change your opinion? I'll be sure to make sure the documentation is quite stern about this though :)

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

Yes, sorry. I'll stop reviewing while distracted, sorry -- more tomorrow.

@aturon

aturon Nov 26, 2014

Member

Yes, sorry. I'll stop reviewing while distracted, sorry -- more tomorrow.

src/libstd/sync/rwlock.rs
+ /// Locks this rwlock with shared read access, blocking the current thread
+ /// until it can be acquired.
+ ///
+ /// The calling thread will be blocked until there are no more writers

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

This is a little unclear: what does "no more writers available" mean? Are there any guarantees about prioritization of writers wrt readers?

@aturon

aturon Nov 26, 2014

Member

This is a little unclear: what does "no more writers available" mean? Are there any guarantees about prioritization of writers wrt readers?

This comment has been minimized.

@alexcrichton

alexcrichton Nov 26, 2014

Member

Ah yes I'll rephrase, I also add comments about how no ordering of contentious lockers is guaranteed (no prioritization yet).

@alexcrichton

alexcrichton Nov 26, 2014

Member

Ah yes I'll rephrase, I also add comments about how no ordering of contentious lockers is guaranteed (no prioritization yet).

+/// // Release our initially acquired resource
+/// sem.release();
+/// ```
+pub struct Semaphore {

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

We should definitely bind to the system semaphores eventually, but this is fine for now.

@aturon

aturon Nov 26, 2014

Member

We should definitely bind to the system semaphores eventually, but this is fine for now.

src/libstd/sync/semaphore.rs
+
+ #[test]
+ fn test_sem_runtime_friendly_blocking() {
+ // Force the runtime to schedule two threads on the same sched_loop.

This comment has been minimized.

@aturon

aturon Nov 26, 2014

Member

I think this comment is out of date :P

@aturon

aturon Nov 26, 2014

Member

I think this comment is out of date :P

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Nov 26, 2014

Member

OK, I've finished reading this over and it looks great! (I didn't scrutinize the OS bindings.)

I think there are a lot of questions going forward about the organization of this module, static variants, and additional system bindings, but this looks like a great step forward. I'm happy for it to land for now, and then we can talk through exactly what we want to stabilize a bit later.

r=me after nits and a rebase.

Member

aturon commented Nov 26, 2014

OK, I've finished reading this over and it looks great! (I didn't scrutinize the OS bindings.)

I think there are a lot of questions going forward about the organization of this module, static variants, and additional system bindings, but this looks like a great step forward. I'm happy for it to land for now, and then we can talk through exactly what we want to stabilize a bit later.

r=me after nits and a rebase.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Nov 27, 2014

Member

Needs a rebase

Member

sfackler commented Nov 27, 2014

Needs a rebase

bors added a commit that referenced this pull request Nov 27, 2014

auto merge of #19274 : alexcrichton/rust/rewrite-sync, r=aturon
This commit is a reimplementation of `std::sync` to be based on the
system-provided primitives wherever possible. The previous implementation was
fundamentally built on top of channels, and as part of the runtime reform it has
become clear that this is not the level of abstraction that the standard level
should be providing. This rewrite aims to provide as thin of a shim as possible
on top of the system primitives in order to make them safe.

The overall interface of the `std::sync` module has in general not changed, but
there are a few important distinctions, highlighted below:

* The condition variable type, `Condvar`, has been separated out of a `Mutex`.
  A condition variable is now an entirely separate type. This separation
  benefits users who only use one mutex, and provides a clearer distinction of
  who's responsible for managing condition variables (the application).

* All of `Condvar`, `Mutex`, and `RWLock` are now directly built on top of
  system primitives rather than using a custom implementation. The `Once`,
  `Barrier`, and `Semaphore` types are still built upon these abstractions of
  the system primitives.

* The `Condvar`, `Mutex`, and `RWLock` types all have a new static type and
  constant initializer corresponding to them. These are provided primarily for C
  FFI interoperation, but are often useful to otherwise simply have a global
  lock. The types, however, will leak memory unless `destroy()` is called on
  them, which is clearly documented.

* The fundamental architecture of this design is to provide two separate layers.
  The first layer is that exposed by `sys_common` which is a cross-platform
  bare-metal abstraction of the system synchronization primitives. No attempt is
  made at making this layer safe, and it is quite unsafe to use! It is currently
  not exported as part of the API of the standard library, but the stabilization
  of the `sys` module will ensure that these will be exposed in time. The
  purpose of this layer is to provide the core cross-platform abstractions if
  necessary to implementors.

  The second layer is the layer provided by `std::sync` which is intended to be
  the thinnest possible layer on top of `sys_common` which is entirely safe to
  use. There are a few concerns which need to be addressed when making these
  system primitives safe:

    * Once used, the OS primitives can never be **moved**. This means that they
      essentially need to have a stable address. The static primitives use
      `&'static self` to enforce this, and the non-static primitives all use a
      `Box` to provide this guarantee.

    * Poisoning is leveraged to ensure that invalid data is not accessible from
      other tasks after one has panicked.

  In addition to these overall blanket safety limitations, each primitive has a
  few restrictions of its own:

    * Mutexes and rwlocks can only be unlocked from the same thread that they
      were locked by. This is achieved through RAII lock guards which cannot be
      sent across threads.

    * Mutexes and rwlocks can only be unlocked if they were previously locked.
      This is achieved by not exposing an unlocking method.

    * A condition variable can only be waited on with a locked mutex. This is
      achieved by requiring a `MutexGuard` in the `wait()` method.

    * A condition variable cannot be used concurrently with more than one mutex.
      This is guaranteed by dynamically binding a condition variable to
      precisely one mutex for its entire lifecycle. This restriction may be able
      to be relaxed in the future (a mutex is unbound when no threads are
      waiting on the condvar), but for now it is sufficient to guarantee safety.

* Condvars support timeouts for their blocking operations. The
  implementation for these operations is provided by the system.

Due to the modification of the `Condvar` API, removal of the `std::sync::mutex`
API, and reimplementation, this is a breaking change. Most code should be fairly
easy to port using the examples in the documentation of these primitives.

[breaking-change]

Closes #17094
Closes #18003

bors added a commit that referenced this pull request Nov 27, 2014

auto merge of #19274 : alexcrichton/rust/rewrite-sync, r=aturon
This commit is a reimplementation of `std::sync` to be based on the
system-provided primitives wherever possible. The previous implementation was
fundamentally built on top of channels, and as part of the runtime reform it has
become clear that this is not the level of abstraction that the standard level
should be providing. This rewrite aims to provide as thin of a shim as possible
on top of the system primitives in order to make them safe.

The overall interface of the `std::sync` module has in general not changed, but
there are a few important distinctions, highlighted below:

* The condition variable type, `Condvar`, has been separated out of a `Mutex`.
  A condition variable is now an entirely separate type. This separation
  benefits users who only use one mutex, and provides a clearer distinction of
  who's responsible for managing condition variables (the application).

* All of `Condvar`, `Mutex`, and `RWLock` are now directly built on top of
  system primitives rather than using a custom implementation. The `Once`,
  `Barrier`, and `Semaphore` types are still built upon these abstractions of
  the system primitives.

* The `Condvar`, `Mutex`, and `RWLock` types all have a new static type and
  constant initializer corresponding to them. These are provided primarily for C
  FFI interoperation, but are often useful to otherwise simply have a global
  lock. The types, however, will leak memory unless `destroy()` is called on
  them, which is clearly documented.

* The fundamental architecture of this design is to provide two separate layers.
  The first layer is that exposed by `sys_common` which is a cross-platform
  bare-metal abstraction of the system synchronization primitives. No attempt is
  made at making this layer safe, and it is quite unsafe to use! It is currently
  not exported as part of the API of the standard library, but the stabilization
  of the `sys` module will ensure that these will be exposed in time. The
  purpose of this layer is to provide the core cross-platform abstractions if
  necessary to implementors.

  The second layer is the layer provided by `std::sync` which is intended to be
  the thinnest possible layer on top of `sys_common` which is entirely safe to
  use. There are a few concerns which need to be addressed when making these
  system primitives safe:

    * Once used, the OS primitives can never be **moved**. This means that they
      essentially need to have a stable address. The static primitives use
      `&'static self` to enforce this, and the non-static primitives all use a
      `Box` to provide this guarantee.

    * Poisoning is leveraged to ensure that invalid data is not accessible from
      other tasks after one has panicked.

  In addition to these overall blanket safety limitations, each primitive has a
  few restrictions of its own:

    * Mutexes and rwlocks can only be unlocked from the same thread that they
      were locked by. This is achieved through RAII lock guards which cannot be
      sent across threads.

    * Mutexes and rwlocks can only be unlocked if they were previously locked.
      This is achieved by not exposing an unlocking method.

    * A condition variable can only be waited on with a locked mutex. This is
      achieved by requiring a `MutexGuard` in the `wait()` method.

    * A condition variable cannot be used concurrently with more than one mutex.
      This is guaranteed by dynamically binding a condition variable to
      precisely one mutex for its entire lifecycle. This restriction may be able
      to be relaxed in the future (a mutex is unbound when no threads are
      waiting on the condvar), but for now it is sufficient to guarantee safety.

* Condvars support timeouts for their blocking operations. The
  implementation for these operations is provided by the system.

Due to the modification of the `Condvar` API, removal of the `std::sync::mutex`
API, and reimplementation, this is a breaking change. Most code should be fairly
easy to port using the examples in the documentation of these primitives.

[breaking-change]

Closes #17094
Closes #18003

bors added a commit that referenced this pull request Nov 27, 2014

auto merge of #19274 : alexcrichton/rust/rewrite-sync, r=aturon
This commit is a reimplementation of `std::sync` to be based on the
system-provided primitives wherever possible. The previous implementation was
fundamentally built on top of channels, and as part of the runtime reform it has
become clear that this is not the level of abstraction that the standard level
should be providing. This rewrite aims to provide as thin of a shim as possible
on top of the system primitives in order to make them safe.

The overall interface of the `std::sync` module has in general not changed, but
there are a few important distinctions, highlighted below:

* The condition variable type, `Condvar`, has been separated out of a `Mutex`.
  A condition variable is now an entirely separate type. This separation
  benefits users who only use one mutex, and provides a clearer distinction of
  who's responsible for managing condition variables (the application).

* All of `Condvar`, `Mutex`, and `RWLock` are now directly built on top of
  system primitives rather than using a custom implementation. The `Once`,
  `Barrier`, and `Semaphore` types are still built upon these abstractions of
  the system primitives.

* The `Condvar`, `Mutex`, and `RWLock` types all have a new static type and
  constant initializer corresponding to them. These are provided primarily for C
  FFI interoperation, but are often useful to otherwise simply have a global
  lock. The types, however, will leak memory unless `destroy()` is called on
  them, which is clearly documented.

* The fundamental architecture of this design is to provide two separate layers.
  The first layer is that exposed by `sys_common` which is a cross-platform
  bare-metal abstraction of the system synchronization primitives. No attempt is
  made at making this layer safe, and it is quite unsafe to use! It is currently
  not exported as part of the API of the standard library, but the stabilization
  of the `sys` module will ensure that these will be exposed in time. The
  purpose of this layer is to provide the core cross-platform abstractions if
  necessary to implementors.

  The second layer is the layer provided by `std::sync` which is intended to be
  the thinnest possible layer on top of `sys_common` which is entirely safe to
  use. There are a few concerns which need to be addressed when making these
  system primitives safe:

    * Once used, the OS primitives can never be **moved**. This means that they
      essentially need to have a stable address. The static primitives use
      `&'static self` to enforce this, and the non-static primitives all use a
      `Box` to provide this guarantee.

    * Poisoning is leveraged to ensure that invalid data is not accessible from
      other tasks after one has panicked.

  In addition to these overall blanket safety limitations, each primitive has a
  few restrictions of its own:

    * Mutexes and rwlocks can only be unlocked from the same thread that they
      were locked by. This is achieved through RAII lock guards which cannot be
      sent across threads.

    * Mutexes and rwlocks can only be unlocked if they were previously locked.
      This is achieved by not exposing an unlocking method.

    * A condition variable can only be waited on with a locked mutex. This is
      achieved by requiring a `MutexGuard` in the `wait()` method.

    * A condition variable cannot be used concurrently with more than one mutex.
      This is guaranteed by dynamically binding a condition variable to
      precisely one mutex for its entire lifecycle. This restriction may be able
      to be relaxed in the future (a mutex is unbound when no threads are
      waiting on the condvar), but for now it is sufficient to guarantee safety.

* Condvars support timeouts for their blocking operations. The
  implementation for these operations is provided by the system.

Due to the modification of the `Condvar` API, removal of the `std::sync::mutex`
API, and reimplementation, this is a breaking change. Most code should be fairly
easy to port using the examples in the documentation of these primitives.

[breaking-change]

Closes #17094
Closes #18003

bors added a commit that referenced this pull request Nov 28, 2014

auto merge of #19274 : alexcrichton/rust/rewrite-sync, r=aturon
This commit is a reimplementation of `std::sync` to be based on the
system-provided primitives wherever possible. The previous implementation was
fundamentally built on top of channels, and as part of the runtime reform it has
become clear that this is not the level of abstraction that the standard level
should be providing. This rewrite aims to provide as thin of a shim as possible
on top of the system primitives in order to make them safe.

The overall interface of the `std::sync` module has in general not changed, but
there are a few important distinctions, highlighted below:

* The condition variable type, `Condvar`, has been separated out of a `Mutex`.
  A condition variable is now an entirely separate type. This separation
  benefits users who only use one mutex, and provides a clearer distinction of
  who's responsible for managing condition variables (the application).

* All of `Condvar`, `Mutex`, and `RWLock` are now directly built on top of
  system primitives rather than using a custom implementation. The `Once`,
  `Barrier`, and `Semaphore` types are still built upon these abstractions of
  the system primitives.

* The `Condvar`, `Mutex`, and `RWLock` types all have a new static type and
  constant initializer corresponding to them. These are provided primarily for C
  FFI interoperation, but are often useful to otherwise simply have a global
  lock. The types, however, will leak memory unless `destroy()` is called on
  them, which is clearly documented.

* The fundamental architecture of this design is to provide two separate layers.
  The first layer is that exposed by `sys_common` which is a cross-platform
  bare-metal abstraction of the system synchronization primitives. No attempt is
  made at making this layer safe, and it is quite unsafe to use! It is currently
  not exported as part of the API of the standard library, but the stabilization
  of the `sys` module will ensure that these will be exposed in time. The
  purpose of this layer is to provide the core cross-platform abstractions if
  necessary to implementors.

  The second layer is the layer provided by `std::sync` which is intended to be
  the thinnest possible layer on top of `sys_common` which is entirely safe to
  use. There are a few concerns which need to be addressed when making these
  system primitives safe:

    * Once used, the OS primitives can never be **moved**. This means that they
      essentially need to have a stable address. The static primitives use
      `&'static self` to enforce this, and the non-static primitives all use a
      `Box` to provide this guarantee.

    * Poisoning is leveraged to ensure that invalid data is not accessible from
      other tasks after one has panicked.

  In addition to these overall blanket safety limitations, each primitive has a
  few restrictions of its own:

    * Mutexes and rwlocks can only be unlocked from the same thread that they
      were locked by. This is achieved through RAII lock guards which cannot be
      sent across threads.

    * Mutexes and rwlocks can only be unlocked if they were previously locked.
      This is achieved by not exposing an unlocking method.

    * A condition variable can only be waited on with a locked mutex. This is
      achieved by requiring a `MutexGuard` in the `wait()` method.

    * A condition variable cannot be used concurrently with more than one mutex.
      This is guaranteed by dynamically binding a condition variable to
      precisely one mutex for its entire lifecycle. This restriction may be able
      to be relaxed in the future (a mutex is unbound when no threads are
      waiting on the condvar), but for now it is sufficient to guarantee safety.

* Condvars support timeouts for their blocking operations. The
  implementation for these operations is provided by the system.

Due to the modification of the `Condvar` API, removal of the `std::sync::mutex`
API, and reimplementation, this is a breaking change. Most code should be fairly
easy to port using the examples in the documentation of these primitives.

[breaking-change]

Closes #17094
Closes #18003
+ assert_eq!(*lock2, 1);
+ tx.send(());
+ });
+ rx.recv();

This comment has been minimized.

@nodakai

nodakai Nov 29, 2014

Contributor

This rx.recv() is nice because the old version couldn't catch a possible assertion failure in the spawned proc. Can we perhaps define a macro to standardize this pattern and to make sure there's no longer any instances of meaningless assert_eq!?

@nodakai

nodakai Nov 29, 2014

Contributor

This rx.recv() is nice because the old version couldn't catch a possible assertion failure in the spawned proc. Can we perhaps define a macro to standardize this pattern and to make sure there's no longer any instances of meaningless assert_eq!?

This comment has been minimized.

@alexcrichton

alexcrichton Dec 5, 2014

Member

This may be somewhat difficult to refactor out into a standard pattern, but for now I'm going to focus on landing this to unblock some more runtime removal.

@alexcrichton

alexcrichton Dec 5, 2014

Member

This may be somewhat difficult to refactor out into a standard pattern, but for now I'm going to focus on landing this to unblock some more runtime removal.

+ let arc2 = arc.clone();
+ let _ = task::try(proc() {
+ let lock = arc2.lock();
+ assert_eq!(*lock, 2);

This comment has been minimized.

@nodakai

nodakai Nov 29, 2014

Contributor

It's hard for humans to check test logs due to these harmless "assertion failure" messages from "poisoning" tests. Can you improve the message like

panic!("intended panic as a part of test scenario ({})", *lock);

The effect should be the same.

@nodakai

nodakai Nov 29, 2014

Contributor

It's hard for humans to check test logs due to these harmless "assertion failure" messages from "poisoning" tests. Can you improve the message like

panic!("intended panic as a part of test scenario ({})", *lock);

The effect should be the same.

+
+ // First, figure out what time it currently is
+ let mut tv = libc::timeval { tv_sec: 0, tv_usec: 0 };
+ let r = ffi::gettimeofday(&mut tv, 0 as *mut _);

This comment has been minimized.

@thestinger

thestinger Dec 3, 2014

Contributor

This isn't correct. You need to use the monotonic clock support. The system time can and will often change.

@thestinger

thestinger Dec 3, 2014

Contributor

This isn't correct. You need to use the monotonic clock support. The system time can and will often change.

This comment has been minimized.

@nodakai

nodakai Dec 4, 2014

Contributor

@thestinger Please remember that Linux CLOCK_MONOTONIC is susceptible to machine hibernation during which TSC doesn't count up. We would have to wait for futex(2) to support CLOCK_BOOTTIME for truly correct timeout operation. So IMHO it's acceptable to live with this code meantime (unless we don't forget that we're repeating the same bugs found in Java bug tracker for long...)

@nodakai

nodakai Dec 4, 2014

Contributor

@thestinger Please remember that Linux CLOCK_MONOTONIC is susceptible to machine hibernation during which TSC doesn't count up. We would have to wait for futex(2) to support CLOCK_BOOTTIME for truly correct timeout operation. So IMHO it's acceptable to live with this code meantime (unless we don't forget that we're repeating the same bugs found in Java bug tracker for long...)

This comment has been minimized.

@alexcrichton

alexcrichton Dec 5, 2014

Member

I don't personally want to debate these details on this PR as this is blocking more runtime removal and reform. I would like to prioritize pushing through this rewrite as much as possible so the wait_timeout functions are now non-public with comments pointing at this PR to review the implementation before making them public.

@alexcrichton

alexcrichton Dec 5, 2014

Member

I don't personally want to debate these details on this PR as this is blocking more runtime removal and reform. I would like to prioritize pushing through this rewrite as much as possible so the wait_timeout functions are now non-public with comments pointing at this PR to review the implementation before making them public.

+ };
+
+ // And wait!
+ let r = ffi::pthread_cond_timedwait(self.inner.get(), mutex::raw(mutex),

This comment has been minimized.

@thestinger

thestinger Dec 3, 2014

Contributor

You should loop until the time is expired. The caller does not have the calculated absolute time, so they have no way of waiting for the appropriate time span. It should take an absolute time instead of a duration if you want the caller to do it.

@thestinger

thestinger Dec 3, 2014

Contributor

You should loop until the time is expired. The caller does not have the calculated absolute time, so they have no way of waiting for the appropriate time span. It should take an absolute time instead of a duration if you want the caller to do it.

This comment has been minimized.

@nodakai

nodakai Dec 4, 2014

Contributor

@thestinger I guess it is assumed that all users of this code should fetch external time/date package such as time or datetime-rs and use it for looping. I'll see if I can push datetime-rs into the standard library so that all I/O and synchronization API with timeout can happily take absolute time parameter.

@nodakai

nodakai Dec 4, 2014

Contributor

@thestinger I guess it is assumed that all users of this code should fetch external time/date package such as time or datetime-rs and use it for looping. I'll see if I can push datetime-rs into the standard library so that all I/O and synchronization API with timeout can happily take absolute time parameter.

@thestinger

This comment has been minimized.

Show comment
Hide comment
@thestinger

thestinger Dec 3, 2014

Contributor

It's painful (but possible) to do timeout support properly on Windows. It should be left out if it's not going to be done correctly because having incorrect implementations is worse than not having the feature.

Contributor

thestinger commented Dec 3, 2014

It's painful (but possible) to do timeout support properly on Windows. It should be left out if it's not going to be done correctly because having incorrect implementations is worse than not having the feature.

std: Rewrite the `sync` module
This commit is a reimplementation of `std::sync` to be based on the
system-provided primitives wherever possible. The previous implementation was
fundamentally built on top of channels, and as part of the runtime reform it has
become clear that this is not the level of abstraction that the standard level
should be providing. This rewrite aims to provide as thin of a shim as possible
on top of the system primitives in order to make them safe.

The overall interface of the `std::sync` module has in general not changed, but
there are a few important distinctions, highlighted below:

* The condition variable type, `Condvar`, has been separated out of a `Mutex`.
  A condition variable is now an entirely separate type. This separation
  benefits users who only use one mutex, and provides a clearer distinction of
  who's responsible for managing condition variables (the application).

* All of `Condvar`, `Mutex`, and `RWLock` are now directly built on top of
  system primitives rather than using a custom implementation. The `Once`,
  `Barrier`, and `Semaphore` types are still built upon these abstractions of
  the system primitives.

* The `Condvar`, `Mutex`, and `RWLock` types all have a new static type and
  constant initializer corresponding to them. These are provided primarily for C
  FFI interoperation, but are often useful to otherwise simply have a global
  lock. The types, however, will leak memory unless `destroy()` is called on
  them, which is clearly documented.

* The `Condvar` implementation for an `RWLock` write lock has been removed. This
  may be added back in the future with a userspace implementation, but this
  commit is focused on exposing the system primitives first.

* The fundamental architecture of this design is to provide two separate layers.
  The first layer is that exposed by `sys_common` which is a cross-platform
  bare-metal abstraction of the system synchronization primitives. No attempt is
  made at making this layer safe, and it is quite unsafe to use! It is currently
  not exported as part of the API of the standard library, but the stabilization
  of the `sys` module will ensure that these will be exposed in time. The
  purpose of this layer is to provide the core cross-platform abstractions if
  necessary to implementors.

  The second layer is the layer provided by `std::sync` which is intended to be
  the thinnest possible layer on top of `sys_common` which is entirely safe to
  use. There are a few concerns which need to be addressed when making these
  system primitives safe:

    * Once used, the OS primitives can never be **moved**. This means that they
      essentially need to have a stable address. The static primitives use
      `&'static self` to enforce this, and the non-static primitives all use a
      `Box` to provide this guarantee.

    * Poisoning is leveraged to ensure that invalid data is not accessible from
      other tasks after one has panicked.

  In addition to these overall blanket safety limitations, each primitive has a
  few restrictions of its own:

    * Mutexes and rwlocks can only be unlocked from the same thread that they
      were locked by. This is achieved through RAII lock guards which cannot be
      sent across threads.

    * Mutexes and rwlocks can only be unlocked if they were previously locked.
      This is achieved by not exposing an unlocking method.

    * A condition variable can only be waited on with a locked mutex. This is
      achieved by requiring a `MutexGuard` in the `wait()` method.

    * A condition variable cannot be used concurrently with more than one mutex.
      This is guaranteed by dynamically binding a condition variable to
      precisely one mutex for its entire lifecycle. This restriction may be able
      to be relaxed in the future (a mutex is unbound when no threads are
      waiting on the condvar), but for now it is sufficient to guarantee safety.

* Condvars now support timeouts for their blocking operations. The
  implementation for these operations is provided by the system.

Due to the modification of the `Condvar` API, removal of the `std::sync::mutex`
API, and reimplementation, this is a breaking change. Most code should be fairly
easy to port using the examples in the documentation of these primitives.

[breaking-change]

Closes #17094
Closes #18003

bors added a commit that referenced this pull request Dec 5, 2014

auto merge of #19274 : alexcrichton/rust/rewrite-sync, r=aturon
This commit is a reimplementation of `std::sync` to be based on the
system-provided primitives wherever possible. The previous implementation was
fundamentally built on top of channels, and as part of the runtime reform it has
become clear that this is not the level of abstraction that the standard level
should be providing. This rewrite aims to provide as thin of a shim as possible
on top of the system primitives in order to make them safe.

The overall interface of the `std::sync` module has in general not changed, but
there are a few important distinctions, highlighted below:

* The condition variable type, `Condvar`, has been separated out of a `Mutex`.
  A condition variable is now an entirely separate type. This separation
  benefits users who only use one mutex, and provides a clearer distinction of
  who's responsible for managing condition variables (the application).

* All of `Condvar`, `Mutex`, and `RWLock` are now directly built on top of
  system primitives rather than using a custom implementation. The `Once`,
  `Barrier`, and `Semaphore` types are still built upon these abstractions of
  the system primitives.

* The `Condvar`, `Mutex`, and `RWLock` types all have a new static type and
  constant initializer corresponding to them. These are provided primarily for C
  FFI interoperation, but are often useful to otherwise simply have a global
  lock. The types, however, will leak memory unless `destroy()` is called on
  them, which is clearly documented.

* The fundamental architecture of this design is to provide two separate layers.
  The first layer is that exposed by `sys_common` which is a cross-platform
  bare-metal abstraction of the system synchronization primitives. No attempt is
  made at making this layer safe, and it is quite unsafe to use! It is currently
  not exported as part of the API of the standard library, but the stabilization
  of the `sys` module will ensure that these will be exposed in time. The
  purpose of this layer is to provide the core cross-platform abstractions if
  necessary to implementors.

  The second layer is the layer provided by `std::sync` which is intended to be
  the thinnest possible layer on top of `sys_common` which is entirely safe to
  use. There are a few concerns which need to be addressed when making these
  system primitives safe:

    * Once used, the OS primitives can never be **moved**. This means that they
      essentially need to have a stable address. The static primitives use
      `&'static self` to enforce this, and the non-static primitives all use a
      `Box` to provide this guarantee.

    * Poisoning is leveraged to ensure that invalid data is not accessible from
      other tasks after one has panicked.

  In addition to these overall blanket safety limitations, each primitive has a
  few restrictions of its own:

    * Mutexes and rwlocks can only be unlocked from the same thread that they
      were locked by. This is achieved through RAII lock guards which cannot be
      sent across threads.

    * Mutexes and rwlocks can only be unlocked if they were previously locked.
      This is achieved by not exposing an unlocking method.

    * A condition variable can only be waited on with a locked mutex. This is
      achieved by requiring a `MutexGuard` in the `wait()` method.

    * A condition variable cannot be used concurrently with more than one mutex.
      This is guaranteed by dynamically binding a condition variable to
      precisely one mutex for its entire lifecycle. This restriction may be able
      to be relaxed in the future (a mutex is unbound when no threads are
      waiting on the condvar), but for now it is sufficient to guarantee safety.

* Condvars support timeouts for their blocking operations. The
  implementation for these operations is provided by the system.

Due to the modification of the `Condvar` API, removal of the `std::sync::mutex`
API, and reimplementation, this is a breaking change. Most code should be fairly
easy to port using the examples in the documentation of these primitives.

[breaking-change]

Closes #17094
Closes #18003
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 5, 2014

Owner

r=aturon

Owner

alexcrichton commented on c3adbd3 Dec 5, 2014

r=aturon

@alexcrichton alexcrichton merged commit c3adbd3 into rust-lang:master Dec 5, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@alexcrichton alexcrichton deleted the alexcrichton:rewrite-sync branch Dec 5, 2014

@vberger vberger referenced this pull request in carllerche/mio Dec 6, 2014

Closed

mpmc_bounded_queue is not longer in Rust std public API #62

rozaliev added a commit to rozaliev/mio that referenced this pull request Dec 8, 2014

add mpmc_bounded_queue
mpmc was removed from stdlib, so we just vendor it for now
(rust-lang/rust#19274)

@aturon aturon referenced this pull request Dec 16, 2014

Closed

Stabilization metabug: 1.0-alpha #19260

140 of 142 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment