Messages in this thread | | | From | Keith Owens <> | Subject | Re: Cache coherency... and locking | Date | Sat, 22 Jul 2000 10:44:15 +1000 |
| |
On Fri, 21 Jul 2000 19:18:27 -0500 (CDT), Oliver Xymoron <oxymoron@waste.org> wrote: >On Sat, 22 Jul 2000, Keith Owens wrote: >> If the data is in task struct *and* you only update it in response to >> requests from the current task then you do not need any locks, the fact >> that you are running under the current task is enough. But if you want >> to update audit flags in one task from another task's context or from >> interrupt then you need a lock. > >It might be possible to have the process get SIGSTOPed so that it can't >proceed while the change is taking place.
If you only update from the current task then you only have one writer (like most of the fields in struct task) so you do not need a lock. If you update from other tasks then you need a lock to prevent concurrent updates. SIGSTOP only prevents the current task from reading the mask while it is being updatad, it does not prevent concurrent updates.
I think Linda needs to define exactly the read and write constraints on this field, how many writers, how many readers, size of field, if multi word can some words be updated without others etc. This question is getting too many "if this then that" responses.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |