Timeline for Lock-Free Ring Implementation
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 8, 2013 at 15:32 | comment | added | CaptainHastings | Hi Christian, thanks once again. I have modified the code to include, what disruptor calls a two-phase commit. In phase 1, producer looks up the entity from the next index in the array and modifies it. In phase 2, it stores it back in the array. The background logger now tracks the phase-2 index. So the background thread will only writes those entities which have been modified and stored. | |
| Jan 7, 2013 at 16:07 | comment | added | Chris Vest | Wrapping around isn't a problem as long as you somehow ensure that you don't overwrite entries that have been consumed. As I read the code (and I could be wrong) it looks like the producer can run ahead of the consumer, overwriting entries that either have not been consumed or are in the process of being consumed, and that's a problem when they are mutable (and mutable entries are part of the point of these kinds of ring-buffers - important for performance by reducing the allocation rate). | |
| Jan 3, 2013 at 18:27 | comment | added | CaptainHastings | Thanks Christian. I do want to let the producers wrap around the ring and overwrite the older entries. Can you please explain how that would make it not thread-safe? Point well taken about bulk reads. I plan to have just one consumer reading from the buffer and on a second look, consumerIndex variable can just be a volatile int (as opposed to AtomicInteger) as it will only be incremented by one consumer thread. Funny that you mention Disruptor. My ring idea is honorably borrowed from Disruptor :) but I wanted to write my own implementation. | |
| Dec 29, 2012 at 23:29 | review | First posts | |||
| Dec 30, 2012 at 8:26 | |||||
| Dec 29, 2012 at 23:09 | history | answered | Chris Vest | CC BY-SA 3.0 |