Messages in this thread | | | Date | Sat, 27 Nov 1999 14:15:22 -0500 (EST) | From | <> | Subject | Re: spin_unlock optimization(i386) |
| |
On Sat, 27 Nov 1999, Gerard Roudier wrote:
> 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/
| |