An Abstraction Technique for Verifying Shared-Memory Concurrencyâ€
Round 1
Reviewer 1 Report
The paper is well-written and improves sufficiently from the previous work.
The major benefit from the approach is on the verification of highly parallelized applications for concurrent execution.
I see pretty interesting the case for the leader algorithm. However, a typical designer of parallel applications would like to know more about the effectiveness against more complex and realistic scenarios. It would be interesting to have a new section discussing the applicability of the method to more use cases of concurrent methods -as MPI protocols- and the formalization in common large-scale applications. For example, authors might consider High-Performance Computing applications.
Since your method is based on expertise deduction, can you formalize for majority of families of actions?
Author Response
Thank you for reviewing our article and providing feedback
on its content! We have made a new version of the submitted article
in which we tried to address all comments raised in the review,
alongside the comments raised by the other reviewers.
We believe that these improved the quality of the article.
** Comment 1 **
>> It would be interesting to have a new section
>> discussing the applicability of the method to more use cases
>> of concurrent methods -as MPI protocols- and the formalization
>> in common large-scale applications.
>> For example, authors might consider
>> High-Performance Computing applications.
We have successfully used the presented approach
in an industrial case study in mid/late 2019.
The results of this have been published elsewhere.
However, we think that this case study clearly highlights
the industrial applicability of the approach,
and therefore added a short new section, 5.4,
that explains what we did and how other industrial
projects can benefit from that.
** Comment 2 **
>> Since your method is based on expertise deduction,
>> can you formalize for majority of families of actions?
We must admit that we do not fully understand this question.
Could you perhaps clarify it a little bit? We would be happy
to address and answer it!
Reviewer 2 Report
Basically I found the paper to be well-written. I only have a few comments.
Section 5: I suppose that the leader election protocol was indeed verified by the proposed approach. If this is the case, statics about the verification, such as the computation time, and machine specification
must be provided. If verification has not been actually conducted in the case study, some justification muse be needed because otherwise the feasibility of the proposed would be seriously blurred.
Seemingly, the paper largely ignores model checking; the proposed approach itself uses the technique in part, though. The very topic of the paper, namely, verification of concurrent programs can often be dealt with model checking, and modular approaches, such as assume-guarantee style reasoning, have been well studied in the context of model checking. The benefits of the proposed approach over model checking techniques should be clearly described in the first section or somewhere else.
In section 1: "..it is very challenging for these logics to be integrated into SMT-based automated verifiers..." Why is the SMT-based approach so important? Are there any other alternatives? Please explain.
Please add citation numbers for VeriFast Vecors, Vipers, etc. when they occur for the first time in the paper.
Page 8: guard: Act->ProcExpr->ProcCond, effect: Act->ProcExpr->ProcCond
I suppose Act is the domain and ProcCond is the codomain; but what is ProcExpr? Please explain this notation,
Author Response
Thank you for reviewing our article and providing feedback
on its content! We have made a new version of the submitted article
in which we tried to address all five comments raised in the review,
alongside the comments raised by the other reviewers.
We believe that these improved the quality of the article.
** Comment 1 **
>> Section 5: I suppose that the leader election protocol
>> was indeed verified by the proposed approach.
>> If this is the case, statics about the verification,
>> such as the computation time, and machine specification
>> must be provided.
A valid remark! The election protocol has indeed been
verified using the presented approach. We added a new section, 5.3,
with specification details and verification times.
** Comment 2 **
>> The benefits of the proposed approach over model checking techniques
>> should be clearly described in the first section or somewhere else.
We extended Section 1.1 with a discussion on the benefits of
the proposed approach compared to model checking.
** Comment 3 **
>> In section 1: "..it is very challenging for these logics
>> to be integrated into SMT-based automated verifiers..."
>> Why is the SMT-based approach so important?
>> Are there any other alternatives? Please explain.
SMT-based verifiers typically provide more automation
than, say, interactive proof assistants like Coq or Isabelle,
which is beneficial for code verification.
Another alternative would be model checking, as discussed in Comment 2.
However, model checkers are typically limited in their ability
to handle data, at least compared to SMT-based verifiers,
due to the risk of running into state-space explosions.
This work aims towards proof automation.
** Comment 4 **
>> Please add citation numbers for VeriFast Vecors, Vipers, etc.
>> when they occur for the first time in the paper.
We added these in the introduction.
** Comment 5 **
>> Page 8: guard: Act->ProcExpr->ProcCond, effect: Act->ProcExpr->ProcCond
>> I suppose Act is the domain and ProcCond is the codomain;
>> but what is ProcExpr? Please explain this notation,
We added a footnote explaining this notation.
We also further clarified the structure
of `guard` and `effect` in the text.
