concurrency - How does LMAX's disruptor pattern work? -
i trying understand disruptor pattern. have watched infoq video , tried read paper. understand there ring buffer involved, initialized extremely large array take advantage of cache locality, eliminate allocation of new memory.
it sounds there 1 or more atomic integers keep track of positions. each 'event' seems unique id , it's position in ring found finding modulus respect size of ring, etc., etc.
unfortunately, don't have intuitive sense of how works. have done many trading applications , studied actor model, looked @ seda, etc.
in presentation mentioned pattern how routers work; haven't found descriptions of how routers work either.
are there pointers better explanation?
the google code project reference technical paper on implementation of ring buffer, bit dry, academic , tough going wanting learn how works. there blog posts have started explain internals in more readable way. there explanation of ring buffer core of disruptor pattern, description of consumer barriers (the part related reading disruptor) , information on handling multiple producers available.
the simplest description of disruptor is: way of sending messages between threads in efficient manner possible. can used alternative queue, shares number of features seda , actors.
compared queues:
the disruptor provides ability pass message onto threads, waking if required (similar blockingqueue). however, there 3 distinct differences.
- the user of disruptor defines how messages stored extending entry class , providing factory preallocation. allows either memory reuse (copying) or entry contain reference object.
- putting messages disruptor 2-phase process, first slot claimed in ring buffer, provides user entry can filled appropriate data. entry must committed, 2-phase approach necessary allow flexible use of memory mentioned above. commit makes message visible consumer threads.
- it responsibility of consumer keep track of messages have been consumed ring buffer. moving responsibility away ring buffer helped reduce amount of write contention each thread maintains own counter.
compared actors
the actor model closer disruptor other programming models, if use batchconsumer/batchhandler classes provided. these classes hide of complexities of maintaining consumed sequence numbers , provide set of simple callbacks when important events occur. however, there couple of subtle differences.
- the disruptor uses 1 thread - 1 consumer model, actors use n:m model i.e. can have many actors , distributed across fixed numbers of threads (generally 1 per core).
- the batchhandler interface provides additional (and important) callback
onendofbatch()
. allows slow consumers, e.g. doing i/o batch events improve throughput. possible batching in other actor frameworks, other frameworks don't provide callback @ end of batch need use timeout determine end of batch, resulting in poor latency.
compared seda
lmax built disruptor pattern replace seda based approach.
- the main improvement provided on seda ability work in parallel. disruptor supports multi-casting same messages (in same order) multiple consumers. avoids need fork stages in pipeline.
- we allow consumers wait on results of other consumers without having put queuing stage between them. consumer can watch sequence number of consumer dependent on. avoids need join stages in pipeline.
compared memory barriers
another way think structured, ordered memory barrier. producer barrier forms write barrier , consumer barrier read barrier.
Comments
Post a Comment