🚀 go-pugleaf

Alan Bellingham wrote:

>Bob Gonder  wrote:
>
>>If there aren't hardware locks in place to ensure non-conflicting
>>atomic read/writes, then Intel is failing in it's job.
>
>Nope - because as Gambit points out, your primitive may require more
>than one access to read or write. At least on the x86 architecture,
>which doesn't insist on DWORDs being DWORD aligned.
>
>In such a case, it ain't atomic any more.

I disagree. The alignment should be inconsequential.
If CPU A is doing a mov  (one cpu instruction) on 2 dwords (due to
misalignment), then those 2 dwords should be locked by the memory
handler (as it does an internal read/modify/write), so that CPU B
can't access them.

Only case where it should be a problem is if the cpu has to update the
value in two parts, as in an int64.

If this were not the case, then we would need to have a LOCK MOV
instruction, which we don't have. We have LOCK INC (etc) because they
access memory for a read-to-cpu, modify in cpu, then write to memory
(possibly creating another read/modify/write internal to the memory).

That is the current state in single-cpu86-land.
Interrups (other than instruction faults) occur between instructions.
LOCK is used to lock memory (and interrupts) for what the book calls
"indivisible read/modify/write cycles" (where the data physicaly
leaves and reenters the memory module).

>My point was that I didn't think the scheduler would interrupt during
>the read or the write. But I'm not sure how low it goes, and whether it
>will interrupt during what is apparently a single CPU operation.

No, except for internal faults, the current instruction is completed
before each interrupt. Other processors, however, may access the same
memory during the course of another processor's instruction (as in
INC). Thus the LOCK modifier.  Single-instruction stores such as MOV
however, must be "safe" or else Intel wouldn't have made LOCK illegal
on them (apparently, it was legal until the 386 came out).

>However, if I remember my assembler, there are some instructions that go
>on for a potential lifetime by CPU clock cycle standards, so maybe it
>does.

That's one of the reasons we don't have "real" real-time os's.
DIV is the longest I know of (other than FP, but they don't count)  at
50 to 100 cycles. But BOUNDS, IRET with taskswitch, run 2-300, but I'd
think the'yd be at the start or end of an interrupt, and not be
subjected to further interrupts.