Implement process_wait #31
Reference in New Issue
Block a user
No description provided.
Delete Branch "process-wait"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Changes:
struct process_resultallows a thread's page to be freed while keeping the result available for the parent (if still alive).process_exit).syscall_execto make some tests work.TODO:
process_result.semaandprocess_result.exit_statusare accessed by potentially multiple threads. We need to synchronise this; however, I don't think locks nor semaphores would work for this due to being too high-level. Lmk any ideas (other than disabling interrupts).exec-multiple.requested review from @td1223
changed the description
added 1 commit
6ed1ccd2- Fix process_result locking by acquiring in process_wait as well to prevent freeing memory too earlyCompare with previous version
marked the checklist item
process_result.semaandprocess_result.exit_statusare accessed by potentially multiple threads. We need to synchronise this; however, I don't think locks nor semaphores would work for this due to being too high-level. Lmk any ideas (other than disabling interrupts). as completedOkay so I've managed to get locks almost to work. Turns out I just needed them in
process_waitto make sure I don't free memory too early.However, I am now getting a deadlock in one of the tests (exec-multiple). I suspect this might have something to do with priority donation not working 100% properly, but still need to debug further.
changed the description
Feel free to revert back to the first few commits of master and try it out. I can't see any deadlock scenario but it is possible.
I’ll give it ago with latest master when I get home, but notice the timeout in the exec-multiple test.
added 1 commit
7778e05a- Fix deadlock by release of lock and semaphore in the wrong orderCompare with previous version
marked the checklist item There's a deadlock in at least
exec-multiple. as completedI haven't quite figured out exactly why this is a problem, but turns out releasing the lock AFTER
sema_upin one of theifbranches was problamatic, so I switched the order.resolved all threads
marked this merge request as ready
added 1 commit
18c88423- Fix race-condition in process result (memory leak), fix infinite loop in donors_listCompare with previous version
Deleted previous comment because it was completely wrong.
So the "working" implementation had a race-condition where if a parent thread dies after the child releases its result lock, but BEFORE it calls
sema_up, then neither thread will free the result, resulting in a memory leak.So revert back to the previous implementation which had a "deadlock". Turns out it wasn't a deadlock, but an infinite loop in the
donors_listcaused by a bug in the priority donation implementation that resulted in threads being part of their owndonors_list.marked the checklist item I need a sanity check about my "child_results is guaranteed to be in-order" comment please 😅 . as completed