struct proc::killed is listed among the variables for which struct proc::lock should be held when used. However, this lock is almost invariably not held when killed is read, and it's also not held when written by usertrap.
As far as I can see, the xv6 book does not discuss this issue. I was wondering whether this is a deliberate choice or an oversight.
I believe, with low confidence, that this is not an issue. As far as I can see, it could only ever be a problem if killed is read as 1 while it is actually 0. Since the value of killed is monotonic during a process' lifetime (it only changes from 0 to 1), this seems impossible to happen even if writes to it are not atomic.
Is this assessment correct? If so, I think it would be nice to clarify this both in the source code and in the book.
struct proc::killedis listed among the variables for whichstruct proc::lockshould be held when used. However, this lock is almost invariably not held whenkilledis read, and it's also not held when written byusertrap.As far as I can see, the xv6 book does not discuss this issue. I was wondering whether this is a deliberate choice or an oversight.
I believe, with low confidence, that this is not an issue. As far as I can see, it could only ever be a problem if
killedis read as 1 while it is actually 0. Since the value ofkilledis monotonic during a process' lifetime (it only changes from 0 to 1), this seems impossible to happen even if writes to it are not atomic.Is this assessment correct? If so, I think it would be nice to clarify this both in the source code and in the book.