It seems to me that one might want to read a large chunk of an object, but
be sure that the entire read completed before any part of the chunk was
modified. To prevent deadlocking, we simply fail the read if part was
modified during the read. How is this implemented for files and memory
chunks? Specific functions to look at would be fine, explanation or
pointers to one would be great.
It also seems to me that one might want to write a large chunk only if the
entire chunk could be written before any unwritten part was read or
written. This is a bit more complicated because with the read, one could
read and simply ignore the value if the call was interupted, but with the
write an interupted write is exactly what we don't want. We need to propose
a set of changes, and then commit it all atomically. Just allowing someone
a lock while they propose changes would deadlock perhaps, the propose/
commit would prevent it I think.
My question is basically, do people actually want to do these things ( i
mean i do, but i also want a modular divide instruction and/or the
abolition of signed instructions). If so, are they provided by the kernel
(either to kernel space or to user space)?
The spin locks and _atomic calls are still a bit greek to me. I'm not sure
if they provide this functionality directly, a similar functionality, or
they are used in some fancy way to provide this.
Any help is greatly appreciated and will put my projects for the kernel one
step closer to completion (though I do seem to be suffering from zeno's
paradoxes).
Side question: I wrote a program that (accidentally) causes ipfirewall to
do some subtle hosing of the kernel. pppd races at 99% in kernel mode (R
but unkillable), inetd deadlocks in kernel mode (D) after a kill signal.
some slight instability with other processes that use networking. I was at
least a little curious what pppd was doing and inetd was waiting for, is
there a patch to have `ps l` show the wchan for those processes?
thanks again,
-Jack
-
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/