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

Rework synchronization primitives - Futex edition #8084

Closed
wants to merge 29 commits into from

Conversation

kprotty
Copy link
Member

@kprotty kprotty commented Feb 27, 2021

See #7800 for initiative and reason for branching into new PR. Don't intend to really add more changes ATM but am willing to accept anymore that come in.

pub fn timestamp() i64 {
return @divFloor(milliTimestamp(), ms_per_s);
}

/// Get a calendar timestamp, in milliseconds, relative to UTC 1970-01-01.
/// Get a calendar timestamp, in nanoseconds, relative to UTC 1970-01-01.
Copy link
Collaborator

Choose a reason for hiding this comment

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

milliTimestamp returns nanoseconds?

Copy link
Member Author

Choose a reason for hiding this comment

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

good point

pub usingnamespace if (@hasDecl(root, "sync"))
root.sync
else if (std.builtin.single_threaded)
primitives.debug
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why is this debug rather than core?

Copy link
Member Author

Choose a reason for hiding this comment

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

core is for algorithms, the "Debug" impls are the "serial" ones. Unfortunate naming.

.{generic.forFutex(os)},
.{generic.forFutex(spin)},
}) |futex| {
// @compileError("TODO: test wait/wake/nanotime");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
// @compileError("TODO: test wait/wake/nanotime");
return error.SkipZigTest; // TODO: test wait/wake/nanotime


const builtin = std.builtin;
const assert = std.debug.assert;
const helgrind: ?type = if (builtin.valgrind_support) std.valgrind.helgrind else null;
Copy link
Collaborator

Choose a reason for hiding this comment

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

You don't need this check, the valgrind module already does it.

}

/// Returns true if the system's high performance timer implementation is actually monotonic.
/// For some platforms, this is not always the case: https://doc.rust-lang.org/src/std/time.rs.html#227
Copy link

Choose a reason for hiding this comment

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

Suggested change
/// For some platforms, this is not always the case: https://doc.rust-lang.org/src/std/time.rs.html#227
/// For some platforms, this is not always the case: https://doc.rust-lang.org/1.50.0/src/std/time.rs.html#227

Copy link

Choose a reason for hiding this comment

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

future versions of rust may move that file/code, so it is better(IMO) to link to a permlink

@@ -1737,3 +1737,56 @@ pub const IOCPARM_MASK = 0x1fff;
fn ior(inout: u32, group: usize, num: usize, len: usize) usize {
return (inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num));
}

pub const KERN_SUCCESS = 0;
Copy link
Collaborator

Choose a reason for hiding this comment

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

This looks like it should be an enum

/// This uses the same method as seen in Amanieu's port of WTF::ParkingLot:
/// https://github.com/Amanieu/parking_lot/blob/master/core/src/parking_lot.rs
fn from(address: usize) *WaitBucket {
const seed = @truncate(usize, 0x9E3779B97F4A7C15);
Copy link
Collaborator

Choose a reason for hiding this comment

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

huh... googling this number shows that it is 2^64 * phi and seems to have a long history of use in wait queues

e.g. https://softwareengineering.stackexchange.com/a/402543

}

pub fn notifyOne(self: *Self) void {
if (helgrind) |hg| {
Copy link
Collaborator

Choose a reason for hiding this comment

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

As mentioned in another comment: no need for this check.

@kubkon
Copy link
Member

kubkon commented Apr 11, 2021

@kprotty could you provide status update on this PR, i.e., do you plan on doing more work on this branch and hopefully merging this upstream in the near future? Or is there a blocker for it or something that I might have missed? I'd be very excited to see this merged.

@kprotty
Copy link
Member Author

kprotty commented Apr 15, 2021

@kubkon Late response, but there are a few blockers:

  • This is old code (an updated version was written after) and instead of discarding it, I was convinced to make it a PR in case someone else wanted to build on top of it. I would prefer to rewrite it all personally.
  • RwLock implementation and related tests are missing
  • Testing for event loop backend of sync primitives is flaky as the test code racy segfaults with std.testing.allocator and reports data races with tsan but cannot be sure if its my evented backend impl or the event loop itself.

@kubkon
Copy link
Member

kubkon commented Apr 19, 2021

@kubkon Late response, but there are a few blockers:

  • This is old code (an updated version was written after) and instead of discarding it, I was convinced to make it a PR in case someone else wanted to build on top of it. I would prefer to rewrite it all personally.
  • RwLock implementation and related tests are missing
  • Testing for event loop backend of sync primitives is flaky as the test code racy segfaults with std.testing.allocator and reports data races with tsan but cannot be sure if its my evented backend impl or the event loop itself.

Ah, gotcha. Thanks for the explanation!

@Vexu
Copy link
Member

Vexu commented Jun 10, 2021

Is this going to be mergeable anytime soon? If not it woud probably be better to close it so that it isn't cluttering the pull requests.

@andrewrk
Copy link
Member

@kprotty you might need to strategize a bit so as to not get overwhelmed and figure out how to break this into smaller, independently mergeable pieces

@kprotty
Copy link
Member Author

kprotty commented Jun 11, 2021

Is this going to be mergeable anytime soon?

@Vexu Most likely no. Its ok to close this given:

figure out how to break this into smaller, independently mergeable pieces

@andrewrk I've been taking this advice. Introduced atomic stuff in #8866, adding Futex in #9070, sync primitives based on Futex after that, then time.Duration/Instant most likely after. Difference between this PR and the current approach is that I won't be touching std.event stuff until #8224 is decided.

@Vexu Vexu closed this Jun 11, 2021
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.

None yet

7 participants