Skip to content

Multithread support v2#240

Closed
lmcarril wants to merge 14 commits into
klee:masterfrom
lmcarril:multithreadv2
Closed

Multithread support v2#240
lmcarril wants to merge 14 commits into
klee:masterfrom
lmcarril:multithreadv2

Conversation

@lmcarril

Copy link
Copy Markdown

A review of the multithread support from Cloud9 presented in pull request: #211
This allows KLEE to execute C programs with pthread and semaphore calls and create new states based on thread scheduling.

In this version have cleaned and formatted the code, and cleaned up the git history (the main reason to open a new pull request).

The main points of the patch are:

1- added to the POSIX runtime a set of pthread calls for thread management, mutexes, condition variables and barriers. The pthread calls use 6 new klee_* special functions to define their behaviour: create, terminate, preempt, sleep, notify, retrieve thread id and retrieve current waiting list.
2- the scheduling is colaborative; the program under test must inform explicitly to KLEE that it can be preempted (using klee_thread_preempt). Some preemption points are hard coded in the pthread call definitions (mostly at the beginning and end of the call). If the user would like to have thread context changes in any other point must insert manually the call.
3- if a thread must wait for a specific action from other thread (mutex release, thread termination...), they are dsiable and put to sleep in a specific waiting list for the relevant event. The thread fulfilling the condition will wake-up one o more threads from the waiting list
4- ExecutionState now is composed by a collection of Threads, each one with its own program counter, incomingBBIndex, call stack. StackFrame struct was moved into the new Thread class. One of the Thread instances will correspond to the current active thread in the state, a set of shortcut methods allows to reference directly the Thread pc, callstack... from the ExecutionState instance.
6- Executor contains a new overloaded fork that clones the current state and add it to the execution pool. The schedule method of Executor is called when a thread is preempted and creates new states for alternative schedules, its behavior depends if the preemption is a real yield, a sleep or only a possible context change.
7- the Thread class keeps an account of each scheduling selection done in each preemption (even if the thread is not preempted at all). This shceduling history is added to the KTest instance; the ktest-tool has been also updated to show the scheduling.
8- new options:
-debug-sched-explored: after terminating an state prints the scheduling steps performed for that state
-debug-sched-history: print in each preemption from which thread to which thread is changing (with fork on schedule more that one new state can appear)
-fork-on-schedule: in each preemption create always new states (fork) for each alternative thread that could become the active one
-scheduler-preemption-bound: limits the number of possible preemptions (not yields) per thread to the given number
-no-scheduler-bound: make the option above unlimited (this increases enormously the number of generated tests)
9- note that the number of generated test cases will grow a lot, because each specific interleaving will reach a different ending state (to minimize this would require implement a partial order reduction algorithm).
10- the Executor::merge method will not merge two states that contains more than one thread, that should maintain the functionality in the sequential case, but I am not sure how that should work for a multithread case.
11- the Cloud9 license is conserved in the new files (directories indicated in LICENSE.TXT)

It would be nice if some (@ccadar, @ddunbar) can give it a try

Luis M. Carril Rodriguez added 12 commits May 8, 2015 16:11
Each ExecutionState has a collection of threads, represented by a Thread object.
Each thread has its own pc, prevPC and stack.
One is the active thread, and current pc and prevPC and stack of the ExecutionState are shortcutted to the corresponding of the active thread.
StackFrame struct and methods moved to Thread class.
Function to create the new thread and bind the starting function, schedule the next in a preemption
and terminate a thread.
@lmcarril lmcarril mentioned this pull request May 11, 2015
@ccadar

ccadar commented May 13, 2015

Copy link
Copy Markdown
Contributor

Thanks, @lmcarril . We have given it a try in our group, but more experimentation and review is needed. I'm very busy this month with various deadlines, but it's on my to do list for June (although other people might be able to review it before then). Sorry for the delay, and thanks for your work on this!

Luis M. Carril Rodriguez added 2 commits June 5, 2015 09:36
…id was used as a flag with 0 as default value, added an explicit flag like the model of a normal mutex
@MartinNowack

Copy link
Copy Markdown
Contributor

@lmcarril Thanks for this PR. This is a great extension. Unfortunately the changes are quite invasive and it would require a substantial refactoring. Currently, there is no capacity for this on our side. I will close this for now but reference it under the KLEE extension project. Still, thanks a lot for all your effort.
(https://github.com/klee/klee/projects/4)

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.

3 participants