Thanks everyone. Another related question. When an atomic integer is used so that writers can claim their segment in the buffer, what prevent wrapping of this atomic integer and falsely assuming you have allocated a section in the buffer?
So imagine the buffer is full, and the atomic integer > buffer.length. Any thread that wants to write, keeps increasing this atomic integer far far beyond its maximum capacity of the buffer. Which in itself is fine because one can detect what kind write failure one had: - first one the over commit - subsequent over commit But what if the value wraps? In theory one could end up thinking one has claimed a segment of memory still needed for reading purposes. One simple way to reduce the problem is to use an atomic long instead of an atomic integer. On Monday, May 29, 2017 at 8:50:22 AM UTC+3, Martin Thompson wrote: > > A related question. What happens if 2 threads do a plain write in the same >> cache line but independent locations. >> >> If this happens concurrently, can the system run into a 'lost update'? >> I'm sure it can't and I guess the cache coherence protocol takes care it. >> But would like to get confirmation anyway. >> > > If the writes are to independent, non-overlapping, addresses then no > update will be lost even if in the same cache line. This will result in > false sharing which is a performance issue but not a correctness issue. > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
