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

Work towards thread safety in rustc #46779

Merged
merged 8 commits into from Dec 22, 2017

Conversation

Projects
None yet
9 participants
@Zoxc
Contributor

Zoxc commented Dec 17, 2017

This PR is split out from #45912. It contains changes which do not require the sync module.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Dec 17, 2017

Collaborator

r? @estebank

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

Collaborator

rust-highfive commented Dec 17, 2017

r? @estebank

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

@Zoxc Zoxc assigned arielb1 and unassigned estebank Dec 17, 2017

Ok(vec.into())
})
}
}

This comment has been minimized.

@bjorn3

bjorn3 Dec 17, 2017

Contributor

Missing trailing newline

@bjorn3

bjorn3 Dec 17, 2017

Contributor

Missing trailing newline

Show outdated Hide outdated src/libsyntax_pos/lib.rs Outdated
Show outdated Hide outdated src/libsyntax_pos/symbol.rs Outdated
@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Dec 17, 2017

Contributor

@bjorn3 Thread-safety for the interners happens in a later commit.

Contributor

Zoxc commented Dec 17, 2017

@bjorn3 Thread-safety for the interners happens in a later commit.

@bjorn3

This comment has been minimized.

Show comment
Hide comment
@bjorn3

bjorn3 Dec 17, 2017

Contributor

@Zoxc that commit doesnt seem to be included in this pr.

Contributor

bjorn3 commented Dec 17, 2017

@Zoxc that commit doesnt seem to be included in this pr.

@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Dec 17, 2017

Contributor

It is in #45912.

Contributor

Zoxc commented Dec 17, 2017

It is in #45912.

@michaelwoerister

This comment has been minimized.

Show comment
Hide comment
@michaelwoerister

michaelwoerister Dec 18, 2017

Contributor

Each PR must leave the compiler in safe/valid state. Implementing Send/Sync for Symbol without making the interners threadsafe is not an option.

Contributor

michaelwoerister commented Dec 18, 2017

Each PR must leave the compiler in safe/valid state. Implementing Send/Sync for Symbol without making the interners threadsafe is not an option.

@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Dec 18, 2017

Contributor

@michaelwoerister The !Send impls are not there for thread safety, but as a way to help ensure that Symbol types are only used with the interner they are created from. This trick no longer works when multiple threads share an interner. It also doesn't work if there are multiple interners per thread (which some of my upcoming patches allow).

Contributor

Zoxc commented Dec 18, 2017

@michaelwoerister The !Send impls are not there for thread safety, but as a way to help ensure that Symbol types are only used with the interner they are created from. This trick no longer works when multiple threads share an interner. It also doesn't work if there are multiple interners per thread (which some of my upcoming patches allow).

@michaelwoerister

This comment has been minimized.

Show comment
Hide comment
@michaelwoerister

michaelwoerister Dec 18, 2017

Contributor

My concern is just that this PR, as it is, would leave the compiler in a state where I can send Symbols between threads and thus get wrong results from the auto-generated Eq implementation. The !Send implementation should only be removed if the same PR makes sure that that cannot lead to logic errors.

Contributor

michaelwoerister commented Dec 18, 2017

My concern is just that this PR, as it is, would leave the compiler in a state where I can send Symbols between threads and thus get wrong results from the auto-generated Eq implementation. The !Send implementation should only be removed if the same PR makes sure that that cannot lead to logic errors.

@@ -42,6 +42,8 @@ use std::cell::{RefCell, Cell};
use std::mem;
use std::rc::Rc;
use std::{error, fmt};
use std::sync::atomic::AtomicUsize;

This comment has been minimized.

@arielb1

arielb1 Dec 18, 2017

Contributor

err_count probably needs to be done in a smarter way than here to assure thread-safety, so could you add a FIXME? In any case this is better than the way before this.

@arielb1

arielb1 Dec 18, 2017

Contributor

err_count probably needs to be done in a smarter way than here to assure thread-safety, so could you add a FIXME? In any case this is better than the way before this.

This comment has been minimized.

@Zoxc

Zoxc Dec 19, 2017

Contributor

In which case is this not thread safe?

@Zoxc

Zoxc Dec 19, 2017

Contributor

In which case is this not thread safe?

let files = self.codemap.files();
if files.len() > 0 {
if self.codemap.files().len() > 0 {

This comment has been minimized.

@arielb1

arielb1 Dec 18, 2017

Contributor

Don't we need a better locking discipline for the codemap? It feels like "too many locks, not enough discipline". Maybe just add a fixme to it?

@arielb1

arielb1 Dec 18, 2017

Contributor

Don't we need a better locking discipline for the codemap? It feels like "too many locks, not enough discipline". Maybe just add a fixme to it?

This comment has been minimized.

@Zoxc

Zoxc Dec 19, 2017

Contributor

Given that I just convert all RefCells into locks, there's probably plenty of places where there are too many locks.

@Zoxc

Zoxc Dec 19, 2017

Contributor

Given that I just convert all RefCells into locks, there's probably plenty of places where there are too many locks.

This comment has been minimized.

@arielb1

arielb1 Dec 21, 2017

Contributor

ok

@arielb1

arielb1 Dec 21, 2017

Contributor

ok

Show outdated Hide outdated src/libsyntax_pos/lib.rs Outdated
Show outdated Hide outdated src/libsyntax_pos/symbol.rs Outdated
@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Dec 21, 2017

Contributor

@bors r=arielb1

Contributor

Zoxc commented Dec 21, 2017

@bors r=arielb1

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 21, 2017

Contributor

📌 Commit 84ce4f1 has been approved by arielb1

Contributor

bors commented Dec 21, 2017

📌 Commit 84ce4f1 has been approved by arielb1

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 22, 2017

Contributor

⌛️ Testing commit 84ce4f1 with merge 2c037d5...

Contributor

bors commented Dec 22, 2017

⌛️ Testing commit 84ce4f1 with merge 2c037d5...

bors added a commit that referenced this pull request Dec 22, 2017

Auto merge of #46779 - Zoxc:par-merge-without-sync, r=arielb1
Work towards thread safety in rustc

This PR is split out from #45912. It contains changes which do not require the `sync` module.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Dec 22, 2017

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 2c037d5 to master...

Contributor

bors commented Dec 22, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 2c037d5 to master...

@bors bors merged commit 84ce4f1 into rust-lang:master Dec 22, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
slot.set(r + 1);
r
});
let id = NEXT_ATTR_ID.fetch_add(1, Ordering::SeqCst);

This comment has been minimized.

@eddyb

eddyb Dec 22, 2017

Member

@rust-lang/compiler Not sure how I feel about this kind of stuff - it will behave non-deterministically in any process running multiple rustc threads in parallel (atm rustc "owns" a thread).
IMO all thread-locals should change to scoped thread locals initialized to point to some memory owned by the thread that started the compilation, if we want multiple threads per rustc "instance".

@eddyb

eddyb Dec 22, 2017

Member

@rust-lang/compiler Not sure how I feel about this kind of stuff - it will behave non-deterministically in any process running multiple rustc threads in parallel (atm rustc "owns" a thread).
IMO all thread-locals should change to scoped thread locals initialized to point to some memory owned by the thread that started the compilation, if we want multiple threads per rustc "instance".

This comment has been minimized.

@Zoxc

Zoxc Dec 22, 2017

Contributor

Good point. I'll make this either a scoped thread local or put it in ParseSess if that happens to be easy.

@Zoxc

Zoxc Dec 22, 2017

Contributor

Good point. I'll make this either a scoped thread local or put it in ParseSess if that happens to be easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment