Skip to content
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

[PROPOSAL] Smart parameter setting #89

Closed
sh-ad opened this issue May 22, 2021 · 3 comments
Closed

[PROPOSAL] Smart parameter setting #89

sh-ad opened this issue May 22, 2021 · 3 comments

Comments

@sh-ad
Copy link

sh-ad commented May 22, 2021

The idea is that after the first run of the scenario, information about the container under test appears. This information can be useful when selecting startup options.

For example, if in some operation, there are two CAS, then you need at least three threads to check.

Therefore, there is a suggestion: to make some tool that can recommend startup parameters after the execution of a scenario.

@sh-ad sh-ad changed the title [PROPOSAL] Estimating the minimum number of threads [PROPOSAL] Smart parameter generation May 22, 2021
@sh-ad sh-ad changed the title [PROPOSAL] Smart parameter generation [PROPOSAL] Smart parameter setting May 22, 2021
@sh-ad
Copy link
Author

sh-ad commented May 22, 2021

The idea is to run the check and, based on the results of one iteration, make some assumptions on how best to run a full-fledged check

To do this, you need to understand which metrics can help in the analysis and how to interpret them.

Metric - the number of CAS in the operation, allows you to determine the minimum number of threads to perform the check

@ndkoval
Copy link
Collaborator

ndkoval commented May 25, 2021

Hi @sh-ad,

That is an interesting and very nice feature to implement! However, it is much more complicated than it seems at first sight.

First, some algorithms do not use CAS-s for synchronization, some use them only for helping, others may use locks in a non-trivial way -- all these situations have to be handled automatically.

Secondly, the numbers of threads and operations in each of them are not the only parameters -- we have to adjust the numbers of iterations (= different scenarios) and invocations for each scenario. Unfortunately, it is quite complicated, especially with the model checking mode, when the number of invocations changes the depth of the analysis. For example, it is sometimes better to use fewer operations in the scenario, automatically increasing the analysis depth. At the same time, some bugs require more operations to be reproduced. How to balance here? In my opinion, there is no silver bullet, and the best configuration depends on the data structure, but we do not have intuition on how exactly it depends. Therefore, now the developer of the data structure specifies the configuration.

All in all, this feature has good potential but requires non-trivial research, so I am not sure that it worth it.

@ndkoval
Copy link
Collaborator

ndkoval commented Feb 17, 2023

As #137 is on the roadmap, I am closing this issue.

@ndkoval ndkoval closed this as completed Feb 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants