Skip to content

Conversation

@RehanChalana
Copy link

@RehanChalana RehanChalana commented Sep 6, 2025

This pr adds support for parallel invocation of solver and adds a new config symbolic.do_parallel_mode.

I could not figure out a nice solution to how can we use parallel invocation when we have to compute solutions from solvers in SymbolicConstraintsGeneral.solve(pc) method because Z3 contexts are not thread safe, The contexts are created in the executor threads but call for getting the solution happens in main thread and it can lead to crashes or concurrency issues.

I am looking for some guidance on it. For now I am using sequential execution in the solve() method but mostly the isSatisfiable() method is used to check if the PC is SAT/UNSAT for path exploration and there parallel invocation is working good!

- add SymbolicConstraintsGeneral.isSatisfiableParallel(pc) and helpers which allows invoking multiple solvers in parallel to solve a PC

- refactor PCParser to be non-static because we need to run different parsers in different threads

- add MultiExecutorCompletionService and ParallelSolverResult which are helper classes for parallel mode

- introduce "symbolic.dp_parallel_mode" config which allows us to set the parallel mode

# Conflicts:
#	jpf-symbc/src/main/gov/nasa/jpf/symbc/numeric/SymbolicConstraintsGeneral.java
- rename ParallelSolverResult to PathConditionResultDTO

- move isSatisfiableSequential() and isSatisfiableParallel() to separate methods

- also move parallel checking of PC to checkPathConditionParallel method
@sohah
Copy link

sohah commented Sep 11, 2025

I could not figure out a nice solution to how can we use parallel invocation when we have to compute solutions from solvers in SymbolicConstraintsGeneral.solve(pc) method because Z3 contexts are not thread safe, The contexts are created in the executor threads but call for getting the solution happens in main thread and it can lead to crashes or concurrency issues.

Hi Rehan,
It sounds like you need to change how we get the model to the main thread. The main thread should not be making any call to collect the model, at least directly from the solving thread. The thread after it is done, should return the model, or even place it in a temp that is later read by the main thread. I think you should be get an object representing the model from the thread after it is done.

@sohah
Copy link

sohah commented Nov 24, 2025

Hi @RehanChalana , any update on that PR?

@RehanChalana
Copy link
Author

Hi! @sohah , I haven’t been able to make further progress on the PR due to college and other commitments. With placement season going on, I may not be able to work on it in the near future either. Apologies for the delay, and thank you for understanding.

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

Successfully merging this pull request may close these issues.

2 participants