Define the structure of task and stack
celizon opened this issue · comments
以下是我和子婷討論出來的內容，需要確認是否理解錯誤和還有想要釐清的問題如下，
task_struct部分：(遇到data race才會存取)
- int pid：紀錄檢測到data race的行程編號
- int cpuid：紀錄執行thread的cpu號碼
- bool read_write_state：紀錄當前變數的讀寫狀態
- void* address：紀錄共享變數在記憶體的位址(同個共享變數，位址是一樣的)
- size_t size：紀錄變數的大小(同個變數，size相同)
detect使用unify的set_task_info(task_struct t)會將發生data race的變數的task資訊傳進unify。如果task的address和size相同，代表是同個共享變數。
可以到task_container裡查詢是否已經有記錄過同個共享變數的資料。task_container是一個二維陣列。例如：當前檢測到行程b裡v1出現data race，而在之前task_container就有存取v1的其他task，所以再把新檢測到的task放進負責紀錄v1的task的陣列裡。
以上是對task的理解。
所以我們可能需要detect負責建立task，或者是傳task內5個需要的值，再由unify負責建立task。
需要解決的疑問：
- 具體需要stack的什麼資訊？我們有想到可以存function call順序、區域變數當前存取的值。
2.一個共享變數只需要存取一個stack_info？還是根據task不同，會存取到多個不同資訊的stack_info？ - **stack的內容會隨著程式的執行不斷變動嗎？**還是會完整記錄執行函式的順序？例如：檢測v1時，它是由func A到B再到C慢慢算出值，在func C才檢測到data race，但先前計算的歷程(有經過func A和B)是不是不會記錄起來？或是說return value後，其他出現data race就無法存到正確的stack，因為stack資訊被更改了？
- 是不是等detect那邊確認所有程式碼的檢測完畢了，再讓detect呼叫unify去做寫檔(void Unify::write_file())，把task_container和stack_info的內容寫進一個txt檔，寫檔完再回到detect？也就是detect負責決定unify寫檔的時機。
task_struct部分：(遇到data race才會存取)
- int pid：紀錄檢測到data race的行程編號
- int cpuid：紀錄執行thread的cpu號碼
- bool read_write_state：紀錄當前變數的讀寫狀態
- void* address：紀錄共享變數在記憶體的位址(同個共享變數，位址是一樣的)
- size_t size：紀錄變數的大小(同個變數，size相同)
detect使用unify的set_task_info(task_struct t)會將發生data race的變數的task資訊傳進unify。
Only the task that found the corresponding watchpoint registered will call the set_task_info() function.
如果task的address和size相同，代表是同個共享變數。
To check the data race occurs, it will use XOR logic to see whether the watchpoint wrote by someone during the delay.
And the work is handled by the task who registers the watchpoint.
But your logic is correct.
可以到task_container裡查詢是否已經有記錄過同個共享變數的資料。task_container是一個二維陣列。例如：當前檢測到行程b裡v1出現data race，而在之前task_container就有存取v1的其他task，所以再把新檢測到的task放進負責紀錄v1的task的陣列裡。
Yes.
以上是對task的理解。 所以我們可能需要detect負責建立task，或者是傳task內5個需要的值，再由unify負責建立task。
The first design will send five parameters, address, object size, access type, return function address, and watchpoint address, to the unify subsystem.
And the first design has already merged with the main branch.
You can see the pull requests here:
需要解決的疑問：
- 具體需要stack的什麼資訊？我們有想到可以存function call順序、區域變數當前存取的值。
We need to get the stack information for each task. Afterward, we can provide more detail about how the data race occurs.
2.一個共享變數只需要存取一個stack_info？還是根據task不同，會存取到多個不同資訊的stack_info？
Yes.
We need to get information from each task.
- **stack的內容會隨著程式的執行不斷變動嗎？**還是會完整記錄執行函式的順序？例如：檢測v1時，它是由func A到B再到C慢慢算出值，在func C才檢測到data race，但先前計算的歷程(有經過func A和B)是不是不會記錄起來？或是說return value後，其他出現data race就無法存到正確的stack，因為stack資訊被更改了？
The stack will change during the task is executed.
I think you should learn the process stack at first.
Here is the website to explain how the stack is.
Stack
The process Stack contains the temporary data such as method/function parameters, return address and local variables.
The stack information we got will have the function calls stack for the task.
For example, we can use backtrace() to get active function calls.
- 是不是等detect那邊確認所有程式碼的檢測完畢了，再讓detect呼叫unify去做寫檔(void Unify::write_file())，把task_container和stack_info的內容寫進一個txt檔，寫檔完再回到detect？也就是detect負責決定unify寫檔的時機。
No.
The detect subsystem will only detect the data race.
It only will send the information it got to the unify subsystem when the data race happens.
Then other information works will handle by the unify subsystem, like collecting environment information and writing the file.