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

Do not box condition variables on Hermit #100583

Closed
wants to merge 1 commit into from

Conversation

joboet
Copy link
Member

@joboet joboet commented Aug 15, 2022

By lazily initializing the internal semaphores, the condition variables do not need to be wrapped in LazyBox.

Ping @mkroening, @stlankes

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Aug 15, 2022
@rustbot
Copy link
Collaborator

rustbot commented Aug 15, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rust-highfive
Copy link
Collaborator

r? @thomcc

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 15, 2022
Copy link
Member

@thomcc thomcc left a comment

Choose a reason for hiding this comment

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

I'm not sure I understand the algorithm in use here (I've dug up the paper but it doesn't actually look similar...), but more generally I'd like to see some checking on error codes -- even just debug_assert, although I think the convention we've adopted elsewhere in std is to start using normal assert for system errors.

sem2 = init_semaphore(&self.sem2);
}

(sem1, sem2)
}

pub unsafe fn notify_one(&self) {
if self.counter.load(SeqCst) > 0 {
self.counter.fetch_sub(1, SeqCst);
Copy link
Member

Choose a reason for hiding this comment

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

This isn't part of the code you've changed, but isn't this a race condition?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes it is. There are other issues: if wait_timeout times out, notify_one does not wake up any thread.

#[cold]
fn init_semaphore(sem: &AtomicPtr<c_void>) -> *mut c_void {
let new = unsafe {
let mut new = MaybeUninit::uninit();
Copy link
Member

Choose a reason for hiding this comment

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

Using MaybeUninit for this is overkill (it's just a pointer) and would result in strange behavior if the sem_init call fails. Given that you ignore it's error, that seems bad.

fn init_semaphore(sem: &AtomicPtr<c_void>) -> *mut c_void {
let new = unsafe {
let mut new = MaybeUninit::uninit();
let _ = abi::sem_init(new.as_mut_ptr(), 0);
Copy link
Member

Choose a reason for hiding this comment

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

Assuming this returns an error code, we should probably assert its success.

match sem.compare_exchange(ptr::null_mut(), new, Release, Acquire) {
Ok(_) => new,
Err(sem) => unsafe {
let _ = abi::sem_destroy(new);
Copy link
Member

Choose a reason for hiding this comment

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

Ditto (re success)

@joboet
Copy link
Member Author

joboet commented Aug 16, 2022

Since there are some issues with the condition variable implementation, I have implemented futex support in the Hermit kernel. That allows us to use the well-tested lock implementations Linux uses, making this PR obsolete.

@joboet joboet closed this Aug 16, 2022
@joboet joboet deleted the hermit_movable_condvar branch August 16, 2022 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants