-
Notifications
You must be signed in to change notification settings - Fork 16
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
Inconsistent function name in RECURSIVE #464
Comments
Made a simple fix for this (maybe it's not good enough). DPLASMA:
PaRSEC:
The compilation issue is fixed. However, there are still issues when recursive is enabled. Here are infos from gdb:
Testing command in DPLASMA:
|
@therault suggests this patch:
After this patch, there is still an issue.
|
The latest PR related to the introduced new issue is: Introduce parsec_taskpool_wait and parsec_taskpool_test by @devreal |
The root of the problem is that in recursive, we try to However, when we use the termination detector for DTD (or for other DSLs like TTG), if we mark the taskpool terminated before calling the callback, we create a race condition: another thread, that is polling the status of the taskpool, can detect it terminated before the callback is called, and move on to the next phase that re-initializes the taskpool to be progressed again, leading to other problems when the callback is finally called (this is the reason why we introduced the status of The same callback cannot be used for both behaviors. One solution (maybe): instead of calling |
We were careful not to touch the taskpool on the way out of the callback, but now we need to go back into the termdet who might still have a pointer to it. Possible but tedious. If we mark the taskpool before calling the callback but we remember that we did it, then the caller (either the callback itself or the main thread) can handle the taskpool as they want/need. Of course they could do bad things, such as the main thread frees the taskpool while we are still calling the callback but that's of little concerns, easily fixed with correct programming. |
We might need to add a dual mechanism as the one we use in OMPI for handling requests, they can be internally completed or externally completed, allowing us a window between the two to handle object related things (like calling the completion callback) |
Describe the bug
The first issue:
DPLASMA_WITH_RECURSIVE
andPARSEC_HAVE_RECURSIVE
are independent; which meansPARSEC_HAVE_RECURSIVE
is alwaysOFF
by default even ifDPLASMA_WITH_RECURSIVE
isON
.The second issue: if
PARSEC_HAVE_RECURSIVE
is enabled manually, DPLASMA can not compile with the following error:I guess it’s because of this commit
To Reproduce
Steps to reproduce the behavior:
PARSEC_HAVE_RECURSIVE
Expected behavior
Compilation failure
Environment (please complete the following information):
Saturn ICL
Additional context
Add any other context about the problem here.
The content of the
config.log
file can be useful in some cases.The text was updated successfully, but these errors were encountered: