> >> Did I miss something obvious? > > > > And this would be a million dollar question here. I don't > > think you did (although Eric (sic) constantly warns us of > > dragons), but on the other hand I have very little > > experience with the kernel itself. > > I hope somebody comments on the fencing that is or isn't needed here. Since > we have parts of the kernel peeking witout locks at ->procctl, I worry about > races, and wonder how, or if, the current design avoids them.
memory fencing only forces the instruction stream to be read, write or r/w coherent with the local processor. it is of no help at all for concurrent access. supposing there is a problem, memory fencing will not help. you would need an ilock. i didn't spend enough time looking at pc/trap.c to convince myself one way or the other, but the main access (other than syscall tracing) seemed to be a read of the variable to transition to stopped state. this race is likely benign. you'll just go around again and catch it later. notes are hard. and the problem they're intended to solve is how to interrupt a single-threaded process. if you're writing something new and you think you might want to extend notes, i think you would be much happier using the thread library and living in user space. > in local store -- that drove the design of the Coyotos kernel to being a > strictly transactional system. AFAIR there it is always possible to tell a it's easy to have a design where you let the dragons play and you need to bring out some serious weaponry to deal with your problems. (and it is possible to get carried away looking for concurrency problems.) a good design like plan 9 keeps the dragons locked up, mostly. - erik
