On 2010-11-20 15:20, Matt Thomas wrote:
On Nov 20, 2010, at 12:25 AM, Johnny Billquist wrote:
Matt,
On 2010-11-13 04:17, Matt Thomas wrote:
The VAX now has a fast non-MP emulation of atomic_cas so that should be
less of an issue.
I looked at this code, as well as your musings about the design. Did you miss
one step in there, or did I miss something?
I think the latter.
I thought that we needed to reset the address pointing location on all
traps/exceptions, but we don't seem to be. So unless an interrupt actually
calls the CAS function, the CAS will happily run to completion no matter how
many intervening interrupt, exceptions and context switches occur.
Not really. We only need to reset the memory address if another CAS interrupts
the current CAS if we make the simplifying assumption that writes to the memory
address will only be done via a CAS operation.
I'm trying to see if this can be a problem, but I'm not sure. But based on your
comments in your design, I seem to read that the idea was that the address
pointer should be reset on every exception.
That would be true if we have naked writes to CAS locations but once you switch
to using CAS, you use CAS for all writes. So the assumption above saves a
little work and makes the RAS have very little overhead.
Thought about it a bit more myself as well, and I think that it's even
ok if someone does a write without using the CAS. Depending on where it
happens in relation to the CAS, it can be considered to happen either
before or after the CAS, which is perfectly reasonable.
The only thing we actually need to protect from is multiple CAS
operations, so I think that the solution is good.
I have had one hang since my new mutex code was "finished", but I don't
know if something else can interfere, since it seems the kernel might be
in a flux at the moment, and I merged in the latest updates yesterday.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol