> 2) Or we have to cross fingers for the CPU to drain the STORE out of
> the write buffer fast enough, but the cost is just a couple of cycles.
>
> Under situation (2), let me write some user code that writes a single
> location and then loops reading it. In case of contention on a spinlock,
> it may well sometimes happen that some other CPUs (31?) be stalled until
> some external event does happen. ;-)
Realistically, I don't think the delay will amount to anything more than
using the lock instruction: as soon as the write propagates through the
store buffers (which would have to be emptied for a locked cycle anyways),
the requests of other cpus to read that location will result in their copy
being updated at the earliest possible time. Of course, a benchmark could
proven me wrong =)
-ben
-
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/