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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:17 EST