-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Convert rust_task_thread::running_tasks list to a queue #2028
Comments
If such a queue was implemented would it be acceptable to not use random indices to schedule tasks? More generally, I'm wondering why tasks are put in random threads and tasks are selected randomly. What's wrong with a simple round robin? |
Yes, part of the goal of switching to the queue is to get rid of the random number generator. I want to switch to round robin thread selection and the queue for task selection (which is effectively round robin). |
Switching to round robin for thread selection is a trivial change that would be easy to do right now. |
@graydon suggested on IRC that using a queue could result in some deadlock situations when contending for external resources like file handles and that enforcing some nondeterminism is necessary. If we had timeslice accounting and enough preemption points then we would presumably use a priority queue based on which tasks deserve more time, and that would also avoid the problem solved by the rng. |
I'm just going to start working on a time slice pqueue branch and see how it turns out |
Just so you know, the compiler doesn't generate any preemption points yet, so the only time that tasks yield is when they explicitly call |
oh, well then, maybe not yet. |
I talked about this more with some colleagues here and did a bit more background reading, and I'm still most comfortable with the existing PRNG-vector scheme. Reasons are as follows:
Basically I want our scheduler to behave -- to outside observers with no reason to believe otherwise -- as much like "running in 1:1 mode" as possible. I want users to face no concurrency "surprises" when changing between 1:1 and M:N modes. Our scheduler is only there to compensate for the fact that running 100,000 threads is too expensive on OSX or windows. If a user really wants a more interesting schedule, they should have to request it: make a separate scheduler, inject some set of threads into it, and ask the OS to run those threads in a particular scheduling model. The OS can provide much finer-grained, faster and more-robust scheduling than we can. |
We're not doing this. Closing. |
We should probably only use info for stats, major compilation steps, and summary of some operations. This reduces the compiler verbosity quite a bit when user runs Kani with --verbose.
Right now it is a list, and scheduling a task involves using a the rng to pick a task and blocking involves removing it from the middle of the list. It would be more efficient (and probably more fair) as a queue. Sort of depends on #1189 and on #2027 in that it would be nice to get rid of the blocked_tasks list as well.
The text was updated successfully, but these errors were encountered: