Allow to check if sync::Once is already initialized #53027

matklad · 2018-08-03T12:57:09Z

Hi!

I propose to expose a way to check if a Once instance is initialized.

I need it in once_cell. OnceCell is effetively a pair of (Once, UnsafeCell<Option<T>>), which can set the T only once. Because I can't check if Once is initialized, I am forced to add an indirection and check the value of ptr instead:

https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L423-L429

https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L457-L461

The parking_lot's version of Once exposes the state as an enum: https://docs.rs/parking_lot/0.6.3/parking_lot/struct.Once.html#method.state.

I suggest, for now, just to add a simple bool function: this fits my use-case perfectly, exposes less implementation details, and is forward-compatible with more fine-grained state checking.

rust-highfive · 2018-08-03T12:57:14Z

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

mzji · 2018-08-03T16:04:13Z

src/libstd/sync/once.rs

+    /// assert!(handle.join().is_err());
+    /// assert_eq!(INIT.is_completed(), false);
+    /// ```
+    #[unstable(feature = "once_is_completed", issue = "42")]


Isn't this issue number wrong? Issue #42 seems totally irrelevant to this code.

It's a placeholder, there's no tracking issue for this yet

Well, I just found that 42 is the answer to everything, however I still hope it could be replaced by the relevant issue ^v^

As soon as @rust-lang/libs decides that we indeed want this feature and creates a tracking issue, I'll update the PR.

Thanks for the explanation!

matklad · 2018-08-04T13:30:41Z

Here's a somewhat better comparison which explains why .is_completed would be neat.

parking lot	std

shepmaster

This feels like a highly abusable / misusable feature from the outside looking in. With such a function, I can see people wrapping their usages of Once with an extra guard "for the fast path". I don't know if that's a real concern or even if it would be an antipattern, but maybe you could chime in on that a bit?

shepmaster · 2018-08-06T02:27:46Z

src/libstd/sync/once.rs

+    ///
+    /// static INIT: Once = Once::new();
+    ///
+    /// assert_eq!(INIT.is_completed(), false);


Think these would normally be written as assert!(INIT.is_completed()) / assert!(!INIT.is_completed())

I think for boolean-returning methods writing an assert_eq! in docs specifically helps a bit with readability. Here's an example from result:

https://doc.rust-lang.org/std/result/enum.Result.html#method.is_ok

shepmaster · 2018-08-06T02:29:55Z

src/libstd/sync/once.rs

+    /// ```
+    #[unstable(feature = "once_is_completed", issue = "42")]
+    pub fn is_completed(&self) -> bool {
+        self.state.load(Ordering::Acquire) == COMPLETE


I'm never smart enough to use any ordering besides SeqCst, but perhaps you can explain why this ordering is appropriate to whoever is clever enough to understand?

Good point! Reshuffled the code a bit to reuse an existing comment :-)

shepmaster · 2018-08-06T02:33:23Z

Passing on to someone smarter...

r? @Kimundi

matklad · 2018-08-06T14:04:21Z

With such a function, I can see people wrapping their usages of Once with an extra guard "for the fast path". I don't know if that's a real concern or even if it would be an antipattern, but maybe you could chime in on that a bit?

Interesting point! It is indeed would be an anti pattern! However, I believe there are cases where you really need to check if once is initialized, without actually initializing it.

For example, a Once may guard initialization of some resource, and some part of code might want to assume that the resources is initialized, without the ability to initialized the resource itself. For example, you might want to have a global logger, initialized in main from command-line arguments. To be able to use the logger in the rest of the program safely, you'll need to get an Option<Logger> somehow, and then unwrap it. And to do be able to differentiate between Some and None, you'll need either is_completed, or to maintain your own atomic state variable, which is error-prone.

Kimundi · 2018-08-08T08:25:49Z

I've also got feature requests for such functionality in the past in lazy_static, so it seems like a useful addition.

@rfcbot fcp merge

rfcbot · 2018-08-08T08:25:50Z

Team member @Kimundi has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

SimonSapin · 2018-08-08T19:36:48Z

@rfcbot document the race condition

I think there is a potential race condition:

is_completed does its atomic load, and returns false
Then another thread completes initialization
Then the first thread acts on the boolean return value, which is now outdated.

This race is probably fine in some cases. I think it is in the use case described by #53027 (comment). But still, this should be mentioned in the doc-comment to try and make callers aware of it.

rfcbot · 2018-08-09T17:23:26Z

🔔 This is now entering its final comment period, as per the review above. 🔔

matklad · 2018-08-09T17:57:37Z

But still, this should be mentioned in the doc-comment to try and make callers aware of it.

Yup, added this case to the doc. Ideally, these all should be formulated in terms of "happens before", but I can't find a short way to express that.

As a non-native speaker, I am also not sure whether it should be is_completed or is_complete.

sfackler · 2018-08-09T19:54:46Z

has_completed?

RalfJung · 2018-08-15T13:53:16Z

Yup, added this case to the doc. Ideally, these all should be formulated in terms of "happens before", but I can't find a short way to express that.

In this case, the intuition I usually try to convey is that the return value is outdated. So people should think of is_completed as saying "at some point in the past (when I was checking), the Once was [not] initialized". That should hopefully make it clear that it might have been initialized since then.

Maybe it should be called was_completed? ;)

SimonSapin · 2018-08-16T08:41:36Z

Oops I messed up the rcfbot command to formally register my concern. But that’s ok, since my concern is resolved now. Thanks!

rfcbot · 2018-08-19T17:33:22Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

pietroalbini · 2018-08-27T15:46:14Z

Ping from triage @Kimundi! The FCP ended.

TimNN · 2018-09-04T17:32:47Z

Ping from triage @Kimundi / @rust-lang/libs: This PR requires your review.

alexcrichton · 2018-09-04T20:45:36Z

@bors: r+

I'm gonna go ahead and r+ this to merge but we can of course continue to bikeshed the name while it's unstable!

bors · 2018-09-04T20:45:37Z

📌 Commit e1bd0e7 has been approved by alexcrichton

bors · 2018-09-05T00:37:15Z

⌛ Testing commit e1bd0e7 with merge f68b7cc...

Allow to check if sync::Once is already initialized Hi! I propose to expose a way to check if a `Once` instance is initialized. I need it in `once_cell`. `OnceCell` is effetively a pair of `(Once, UnsafeCell<Option<T>>)`, which can set the `T` only once. Because I can't check if `Once` is initialized, I am forced to add an indirection and check the value of ptr instead: https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L423-L429 https://github.com/matklad/once_cell/blob/8127a81976c3f2f4c0860562c3f14647ebc025c0/src/lib.rs#L457-L461 The `parking_lot`'s version of `Once` exposes the state as an enum: https://docs.rs/parking_lot/0.6.3/parking_lot/struct.Once.html#method.state. I suggest, for now, just to add a simple `bool` function: this fits my use-case perfectly, exposes less implementation details, and is forward-compatible with more fine-grained state checking.

bors · 2018-09-05T03:04:15Z

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing f68b7cc to master...

eddyb · 2018-09-29T07:02:26Z

src/libstd/sync/once.rs

+    /// assert_eq!(INIT.is_completed(), false);
+    /// ```
+    #[unstable(feature = "once_is_completed", issue = "42")]
+    pub fn is_completed(&self) -> bool {


Once is not generic, so this is missing an #[inline]. (@anp found a rayon bench regression likely caused by this)

https://blog.anp.lol/lolbench-data/benchmarks/rayon-1-0-0-find-serial-find-first.html fwiw

@eddyb is that documented in the api guidelines or somewhere similar?

Fixed in #54662

@matklad

Fix tracking issue for Once::is_completed rust-lang#53027 was merged without a tracking issue. I just filed rust-lang#54890. CC @matklad

@matklad

Fix tracking issue for Once::is_completed rust-lang#53027 was merged without a tracking issue. I just filed rust-lang#54890. CC @matklad

@matklad

Fix tracking issue for Once::is_completed rust-lang#53027 was merged without a tracking issue. I just filed rust-lang#54890. CC @matklad

@matklad

Fix tracking issue for Once::is_completed rust-lang#53027 was merged without a tracking issue. I just filed rust-lang#54890. CC @matklad

Allow to check if sync::Once is initialized

6aba6f9

rust-highfive assigned shepmaster Aug 3, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 3, 2018

mzji reviewed Aug 3, 2018

View reviewed changes

kennytm added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Aug 5, 2018

shepmaster reviewed Aug 6, 2018

View reviewed changes

rust-highfive assigned Kimundi and unassigned shepmaster Aug 6, 2018

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Aug 8, 2018

rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Aug 9, 2018

Reduce code duplication in Once

e1bd0e7

matklad force-pushed the once_is_completed branch from 959f88a to e1bd0e7 Compare August 9, 2018 17:50

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Aug 19, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 4, 2018

bors merged commit e1bd0e7 into rust-lang:master Sep 5, 2018

eddyb reviewed Sep 29, 2018

View reviewed changes

This was referenced Oct 7, 2018

Tracking issue for std::sync::Once::is_completed #54890

Closed

Fix tracking issue for Once::is_completed #54891

Merged

matklad deleted the once_is_completed branch July 9, 2019 12:33

Allow to check if sync::Once is already initialized #53027

Allow to check if sync::Once is already initialized #53027

Uh oh!

Conversation

matklad commented Aug 3, 2018

Uh oh!

rust-highfive commented Aug 3, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mzji Aug 6, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matklad commented Aug 4, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shepmaster left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shepmaster commented Aug 6, 2018

Uh oh!

matklad commented Aug 6, 2018

Uh oh!

Kimundi commented Aug 8, 2018

Uh oh!

rfcbot commented Aug 8, 2018 • edited by sfackler Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SimonSapin commented Aug 8, 2018

Uh oh!

rfcbot commented Aug 9, 2018

Uh oh!

matklad commented Aug 9, 2018

Uh oh!

sfackler commented Aug 9, 2018

Uh oh!

RalfJung commented Aug 15, 2018

Uh oh!

SimonSapin commented Aug 16, 2018

Uh oh!

rfcbot commented Aug 19, 2018

Uh oh!

pietroalbini commented Aug 27, 2018

Uh oh!

TimNN commented Sep 4, 2018

Uh oh!

alexcrichton commented Sep 4, 2018

Uh oh!

bors commented Sep 4, 2018

Uh oh!

bors commented Sep 5, 2018

Uh oh!

bors commented Sep 5, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mzji Aug 6, 2018 •

edited

Loading

matklad commented Aug 4, 2018 •

edited

Loading

rfcbot commented Aug 8, 2018 •

edited by sfackler

Loading