-
Notifications
You must be signed in to change notification settings - Fork 506
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
Make it possible to disable the cross pool dispatch optimization. #765
base: main
Are you sure you want to change the base?
Conversation
I disagree with calling this work stealing an optimization -- as you note, there's a deadlock possibility without it. But reentrancy can cause its own deadlocks, so... it's complicated. The other thing to to consider is whether this should really be a pool-wide option, versus a specific method for this behavior, perhaps |
@khuey can you say a bit more about what you are doing that you want this option? I guess you are invoking |
I'm on thread pool A and I invoke |
Maybe we could document this better? We currently say, "it will block until all tasks that have been spawned into
This would be a hazard for any kind of blocking, even local to one thread pool. For example, if the second half of a I mentioned in #690 (comment) that we could have a "critical section" primitive that prevents work-stealing on the current thread. You would want that for the duration of your |
I don't quite understand the ref-cell scenario. Ref-cells can't be shared across threads, so you must have some master task that owns the ref-cell. How could a re-entrant task try to access it? |
In other words, I believe that an task that we might execute while blocked here could also be stolen and executed by some other available thread if there were one -- am I missing something? |
The RefCell lives in TLS. |
I see, so you have some "per-thread" resources and you want to "truly block". OK. |
Now that I understand the situation better, I think I agree with @cuviper that focusing on "cross-thread blocking" doesn't seem right -- this is really about wanting any sort of blocking to hold off on executing tasks. I guess that you're just very careful not to hold the ref-cell across any "intra-pool parallel operations", @khuey? The "critical section" idea is interesting and seems somewhat more general -- I guess that there is never a need for a thread to do anything but block while it blocks, there should always be some thread still executing and making progress. I could also imagine just configuring a thread-pool to have all blocking operations "just block" and not steal while blocking. I'm not sure @khuey if this would work for what you're doing or not. |
I don't think we use any intra-pool parallel operations. Edit (in the relevant section, anyways). |
@khuey OK, I guess the idea is that each task in pool A is a "leaf task" that doesn't spawn any more tasks, except for some in other pools? |
I would like to dust this off so I can finally stop using scoped-pool for one of the thread pools.
Yes, I believe this would work for me. Would you take a PR that implements this? |
This optimization can lead to unexpected reentrancy when using multiple rayon threadpools.