www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - the Disruptor framework vs The Complexities of Concurrency

reply "Nick B" <nick.barbalich gmail.com> writes:
 [Andrei's comment ] Cross-pollination is a good thing indeed.
I came across this while searching the programme of the conference that Walter is attending in Australia. This gentleman, Martin Thompson http://www.yowconference.com.au/general/details.html?speakerId=2962 The main idea, is in this paper (11 pages, pdf): http://disruptor.googlecode.com/files/Disruptor-1.0.pdf and here is a review of the architecure by Martin Fowler: http://martinfowler.com/articles/lmax.html My questions are: 1. Is this pattern worth porting to the standard library ? 2. Is this pattern a replacement for the 'Complexity of Concurrency' ? cheers Nick B
Dec 07 2012
parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Friday, 7 December 2012 at 09:00:48 UTC, Nick B wrote:
 [Andrei's comment ] Cross-pollination is a good thing indeed.
I came across this while searching the programme of the conference that Walter is attending in Australia. This gentleman, Martin Thompson http://www.yowconference.com.au/general/details.html?speakerId=2962 The main idea, is in this paper (11 pages, pdf): http://disruptor.googlecode.com/files/Disruptor-1.0.pdf and here is a review of the architecure by Martin Fowler: http://martinfowler.com/articles/lmax.html My questions are: 1. Is this pattern worth porting to the standard library ? 2. Is this pattern a replacement for the 'Complexity of Concurrency' ? cheers Nick B
You can find few presentation from LMAX guys on InfoQ. Pretty neat stuff if you ask me. I think someone already worked on Disruptor-like project in D. I would not like to have the whole thing in Phobos, just some "basic blocks".
Dec 07 2012
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 7 December 2012 at 09:03:58 UTC, Dejan Lekic wrote:
 On Friday, 7 December 2012 at 09:00:48 UTC, Nick B wrote:
 [Andrei's comment ] Cross-pollination is a good thing indeed.
I came across this while searching the programme of the conference that Walter is attending in Australia. This gentleman, Martin Thompson http://www.yowconference.com.au/general/details.html?speakerId=2962 The main idea, is in this paper (11 pages, pdf): http://disruptor.googlecode.com/files/Disruptor-1.0.pdf and here is a review of the architecure by Martin Fowler: http://martinfowler.com/articles/lmax.html My questions are: 1. Is this pattern worth porting to the standard library ? 2. Is this pattern a replacement for the 'Complexity of Concurrency' ? cheers Nick B
You can find few presentation from LMAX guys on InfoQ. Pretty neat stuff if you ask me. I think someone already worked on Disruptor-like project in D. I would not like to have the whole thing in Phobos, just some "basic blocks".
Actually, this is what should be behind message passing in phobos IMO. Much better than what we currently have. I wanted to do that at the time, but it wasn't possible without asm. You'll find post about that if you dig deep engough in that newsgroup.
Dec 07 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/7/2012 1:43 PM, deadalnix пишет:
 On Friday, 7 December 2012 at 09:03:58 UTC, Dejan Lekic wrote:
 On Friday, 7 December 2012 at 09:00:48 UTC, Nick B wrote:
 [Andrei's comment ] Cross-pollination is a good thing indeed.
I came across this while searching the programme of the conference that Walter is attending in Australia. This gentleman, Martin Thompson http://www.yowconference.com.au/general/details.html?speakerId=2962 The main idea, is in this paper (11 pages, pdf): http://disruptor.googlecode.com/files/Disruptor-1.0.pdf and here is a review of the architecure by Martin Fowler: http://martinfowler.com/articles/lmax.html My questions are: 1. Is this pattern worth porting to the standard library ? 2. Is this pattern a replacement for the 'Complexity of Concurrency' ? cheers Nick B
You can find few presentation from LMAX guys on InfoQ. Pretty neat stuff if you ask me. I think someone already worked on Disruptor-like project in D. I would not like to have the whole thing in Phobos, just some "basic blocks".
Actually, this is what should be behind message passing in phobos IMO. Much better than what we currently have. I wanted to do that at the time, but it wasn't possible without asm. You'll find post about that if you dig deep engough in that newsgroup.
The stuff is an amazingly cool pattern. TI just think there are some limitations of applicability though. Producer has to read all of sequence counters of its final consumers so as to not to stomp on their slots. And indeed 1P-3C is the least shiny column. I suspect if one ups the number of "sink"-kind consumers it starts to give in. Thus I think it's not fit to arbitrary graphs of actors that are constructed & destroyed at run-time like in std.concurrency. Keep in mind that in model we currently have relations between actors are not fixed anywhere and more importantly not every message have to be seen by every consumer even eventually. And it's not a producer-_consumers_ either. I mean that 'consumer' implies it consumes the item and that other consumers won't see it. Looking at the graphs in: http://martinfowler.com/articles/lmax.html It's obvious what the thing truly models - a hierarchical pipeline where each direct "consumer" visits each of the requests once. Then dependent consumers (further down the hierarchy) can visit it and so forth till the bottom. The last ones are the "sink" that effectively consumes item. The terms multi-pass and multi-stage is more to the point here. To compare these two different views: Producer-consumer is a kind of a workflow where worker grubs material from input "gate" and does everything on it alone then passes it to the next "gate". The scalability is achieved by having a lot of workers that each does the whole work independently (and able to do so!). The advantage is that you never have a half-baked work unit: it either waits, in process or done. There is no stage of "semi-done". Also it's trivially balanced: - queue accumulates too fast - grow consumers pool, shrink producer pool - queue is near empty - grow more producers, shrink consumers pool So there is a world of tuning but the levers are easy to understand. In a sense this scheme scales nicely with the amount of messages just not with the number of *independent* *parallel* processing steps per each message. The pipeline described in Disrupter is more like a factory pipeline where you have a large rotating transporter and workers are standing around it. It's just that in this case it's workers moving around it instead of central rotation (and its better as speeds of different stages goes up and down). Then there is one (or many) that puts material and goes forward, other workers are doing their own passes and advance until they have to wait on the producer (or the worker of the previous stage). Indeed emulating the second concept with queues that can only take/put is embarrassing as you'd have to split queues on each stage and put copies of references to items into them (in Java it's always the case). So the last problem is I don't see how it cleanly scales with the number of messages: there is only one instance of a specific consumer type on each stage. How do these get scaled if one core working on each is not enough? -- Dmitry Olshansky
Dec 07 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 07 Dec 2012 19:55:50 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 12/7/2012 1:43 PM, deadalnix =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 On Friday, 7 December 2012 at 09:03:58 UTC, Dejan Lekic wrote:
 On Friday, 7 December 2012 at 09:00:48 UTC, Nick B wrote:
 [Andrei's comment ] Cross-pollination is a good thing indeed.
I came across this while searching the programme of the conference that Walter is attending in Australia. This gentleman, Martin Thompson http://www.yowconference.com.au/general/details.html?speakerId=3D2962 The main idea, is in this paper (11 pages, pdf): http://disruptor.googlecode.com/files/Disruptor-1.0.pdf and here is a review of the architecure by Martin Fowler: http://martinfowler.com/articles/lmax.html
Fascinating.
=20
 So the last problem is I don't see how it cleanly scales with the
 number of messages: there is only one instance of a specific consumer
 type on each stage. How do these get scaled if one core working on
 each is not enough?
=20
As Fowler's articles mentions at one point, you can have multiple consumers of the same type working concurrently on the same ring by just simply having each of them skip every N-1 items (for N consumers of the same type. Ie, if you have two consumers of the same type, one
Dec 08 2012
next sibling parent "Rob T" <rob ucora.com> writes:
On Saturday, 8 December 2012 at 17:08:55 UTC, Nick Sabalausky 
wrote:
 Fascinating.

 
 So the last problem is I don't see how it cleanly scales with 
 the
 number of messages: there is only one instance of a specific 
 consumer
 type on each stage. How do these get scaled if one core 
 working on
 each is not enough?
 
As Fowler's articles mentions at one point, you can have multiple consumers of the same type working concurrently on the same ring by just simply having each of them skip every N-1 items (for N consumers of the same type. Ie, if you have two consumers of the same type, one
Yes I was getting the sense of that while quickly reading through it. If my understanding is correct, it seems that you can have levels of rings and consumers operating like a pipelining system from one stage to another to scale up to multiple cpus. I need to sit down and read this in detail, it's very interesting. Of particular interest to me, is the part where they store in non-volatile memory the messages coming in, so that when the system goes down, it can be brought back up to the previous state by replaying the messages. They also use that system to replicate multiple redundant copies so that should the live service goes down, one of the redundant copies can immediately go live in a very short period of time. One concern I have though, is how generalized the approach is, or if it is suitable only for certain specialized situations. Also how scalable it is in terms of complexity with being able to manage the scaling. Note too the mention of issues with the GC, which forced certain design decisions, although even without a GC, the design choices may still be the best ones to use. --rt
Dec 08 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/8/2012 9:08 PM, Nick Sabalausky пишет:
 On Fri, 07 Dec 2012 19:55:50 +0400
 Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 12/7/2012 1:43 PM, deadalnix пишет:
 On Friday, 7 December 2012 at 09:03:58 UTC, Dejan Lekic wrote:
 On Friday, 7 December 2012 at 09:00:48 UTC, Nick B wrote:
 [Andrei's comment ] Cross-pollination is a good thing indeed.
I came across this while searching the programme of the conference that Walter is attending in Australia. This gentleman, Martin Thompson http://www.yowconference.com.au/general/details.html?speakerId=2962 The main idea, is in this paper (11 pages, pdf): http://disruptor.googlecode.com/files/Disruptor-1.0.pdf and here is a review of the architecure by Martin Fowler: http://martinfowler.com/articles/lmax.html
Fascinating.
 So the last problem is I don't see how it cleanly scales with the
 number of messages: there is only one instance of a specific consumer
 type on each stage. How do these get scaled if one core working on
 each is not enough?
As Fowler's articles mentions at one point, you can have multiple consumers of the same type working concurrently on the same ring by just simply having each of them skip every N-1 items (for N consumers of the same type. Ie, if you have two consumers of the same type, one
I thought about that even-odd style but it muddies waters a bit. Now producers or however comes next the "circle" have to track all of the split-counters (since they could outpace each other at different times). The other way is to have them contend on a single counter with CAS but again not as nice. The other moment is that system becomes that more dependent on a single component failure and they get around this be running multiple copies of the whole system in sync. A wise move to ensure stability of a complex system (and keeping in mind the stack exchange reliability requirements). -- Dmitry Olshansky
Dec 08 2012
parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Saturday, 8 December 2012 at 19:54:29 UTC, Dmitry Olshansky 
wrote:
 12/8/2012 9:08 PM, Nick Sabalausky пишет:
 On Fri, 07 Dec 2012 19:55:50 +0400
 Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 12/7/2012 1:43 PM, deadalnix пишет:
 On Friday, 7 December 2012 at 09:03:58 UTC, Dejan Lekic 
 wrote:
 On Friday, 7 December 2012 at 09:00:48 UTC, Nick B wrote:
 [Andrei's comment ] Cross-pollination is a good thing 
 indeed.
I came across this while searching the programme of the conference that Walter is attending in Australia. This gentleman, Martin Thompson http://www.yowconference.com.au/general/details.html?speakerId=2962 The main idea, is in this paper (11 pages, pdf): http://disruptor.googlecode.com/files/Disruptor-1.0.pdf and here is a review of the architecure by Martin Fowler: http://martinfowler.com/articles/lmax.html
Fascinating.
 So the last problem is I don't see how it cleanly scales with 
 the
 number of messages: there is only one instance of a specific 
 consumer
 type on each stage. How do these get scaled if one core 
 working on
 each is not enough?
As Fowler's articles mentions at one point, you can have multiple consumers of the same type working concurrently on the same ring by just simply having each of them skip every N-1 items (for N consumers of the same type. Ie, if you have two consumers of the same type, one
I thought about that even-odd style but it muddies waters a bit. Now producers or however comes next the "circle" have to track all of the split-counters (since they could outpace each other at different times). The other way is to have them contend on a single counter with CAS but again not as nice. The other moment is that system becomes that more dependent on a single component failure and they get around this be running multiple copies of the whole system in sync. A wise move to ensure stability of a complex system (and keeping in mind the stack exchange reliability requirements).
Would Andrei like to comment on any of the comments so far ??
Dec 09 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/9/12 10:58 PM, Nick B wrote:
[about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern? Andrei
Dec 10 2012
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 10 December 2012 at 20:08:32 UTC, Andrei Alexandrescu 
wrote:
 On 12/9/12 10:58 PM, Nick B wrote:
 [about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern?
Indeed, I felt the same with that paper. I suggest you read : http://blog.codeaholics.org/2011/the-disruptor-lock-free-publishing/ http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-how-do-i-read-from.html http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-whats-so-special.html http://mechanitis.blogspot.com/2011/07/dissecting-disruptor-writing-to-ring.html
Dec 10 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Monday, 10 December 2012 at 20:08:32 UTC, Andrei Alexandrescu 
wrote:
 On 12/9/12 10:58 PM, Nick B wrote:
 [about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern? Andrei
http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work A couple of posts in there attempt to summarize what it is. One of them compares it against a few other strategies. --rt
Dec 10 2012
prev sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Monday, 10 December 2012 at 20:08:32 UTC, Andrei Alexandrescu 
wrote:
 On 12/9/12 10:58 PM, Nick B wrote:
 [about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern? Andrei
I have looked, but I think the answer is to this question is no. Nick
Dec 10 2012
next sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
 On Monday, 10 December 2012 at 20:08:32 UTC, Andrei 
 Alexandrescu wrote:
 On 12/9/12 10:58 PM, Nick B wrote:
 [about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern?
Ok, does anyone consider that this pattern, though not well described, has any value ? Nick
Dec 11 2012
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 12 December 2012 at 02:00:26 UTC, Nick B wrote:
 Ok, does anyone consider that this pattern, though not well 
 described, has any value ?
I do.
Dec 11 2012
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/12/2012 6:00 AM, Nick B пишет:
 On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
 On Monday, 10 December 2012 at 20:08:32 UTC, Andrei Alexandrescu wrote:
 On 12/9/12 10:58 PM, Nick B wrote:
 [about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern?
Ok, does anyone consider that this pattern, though not well described, has any value ? Nick
It surely has. I'd consider http://martinfowler.com/articles/lmax.html to be quite nice description as it helped me to decipher the most of details. The paper itself lacks illustrative material, focuses too much on overcoming Java limitations and generally too terse with important (to me) details of the framework. -- Dmitry Olshansky
Dec 12 2012
next sibling parent reply "renoX" <renozyx gmail.com> writes:
On Wednesday, 12 December 2012 at 08:09:40 UTC, Dmitry Olshansky 
wrote:
 12/12/2012 6:00 AM, Nick B пишет:
 On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
[cut]
 Ok, does anyone consider that this pattern, though not well 
 described,
 has any value ?

 Nick
It surely has.
Maybe, but I'm still not clear what are the differences between a normal ring buffer (not a new concept) and this "disruptor" pattern.. BR, renoX
Dec 12 2012
parent reply "David Piepgrass" <qwertie256 gmail.com> writes:
 Maybe, but I'm still not clear what are the differences between 
 a normal ring buffer (not a new concept) and this "disruptor" 
 pattern..
Key differences with a typical lock-free queue: - Lightning fast when used correctly. It observes that not only is locking expensive, even CAS (compare and swap) is not cheap, so it avoids CAS in favor of memory barriers (unless multiple writers are required.) Memory allocation is avoided too, by preallocating everything. - Multicast and multisource: multiple readers can view the same entries. - Separation of concerns: disruptors are a whole library instead of a single class, so disruptors support several configurations of producers and consumers, as opposed to a normal queue that is limited to one or two arrangements. To me, one particularly interesting feature is that a reader can modify an entry and then another reader can flag itself as "dependent" on the output of the first reader. So really it supports not just readers and writers but "annotators" that both read an write. And the set of readers and writers can be arranged as a graph. See also http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work
Dec 12 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/13/2012 4:59 AM, David Piepgrass пишет:
 Maybe, but I'm still not clear what are the differences between a
 normal ring buffer (not a new concept) and this "disruptor" pattern..
Key differences with a typical lock-free queue:
Nice summary. I wasn't sure where should I describing that it's not "just a ring buffer". But for start I'd define it is a framework for concurrent processing of a stream of tasks/requests/items on a well structured multi-staged pipeline.
 - Lightning fast when used correctly. It observes that not only is
 locking expensive, even CAS (compare and swap) is not cheap, so it
 avoids CAS in favor of memory barriers (unless multiple writers are
 required.) Memory allocation is avoided too, by preallocating everything.
 - Multicast and multisource: multiple readers can view the same entries.
 - Separation of concerns: disruptors are a whole library instead of a
 single class, so disruptors support several configurations of producers
 and consumers, as opposed to a normal queue that is limited to one or
 two arrangements. To me, one particularly interesting feature is that a
 reader can modify an entry and then another reader can flag itself as
 "dependent" on the output of the first reader.
And the producer in the end depends on the last consumers in this graph. There is also highly flexible (policy-based design) selection of how consumers wait on data: - either busy _spin_ on it thus getting the highest responsiveness at the cost of wasted CPU cycles - lazy spin (that yields) no outright burning of CPU resources but higher latency - and even locking with wait-notify that saves greatly on CPU but kills responsiveness and throughput (but gives freedom to spend CPU elsewhere) Plus there are different strategies for multi-prioducer or single-producer setup.
So really it supports not
 just readers and writers but "annotators" that both read an write. And
 the set of readers and writers can be arranged as a graph.
Yeah, to me it indicates multi-thread-friendly multi-pass processing. Another important IMHO observation is that the order of processed items is preserved* and this is interesting property if you consider doing the same stages as lock-free queues with a pool of consumers at each stage. Things will get O-o-O very quickly. *That was stressed in the article about LMAX i.e. a trade depends on the order of other trades. So if your trade happens later then expected (or earlier) it going to be a different trade.
 See also
 http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work
-- Dmitry Olshansky
Dec 13 2012
parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Thursday, 13 December 2012 at 16:07:13 UTC, Dmitry Olshansky 
wrote:
 12/13/2012 4:59 AM, David Piepgrass пишет:
 Maybe, but I'm still not clear what are the differences 
 between a
 normal ring buffer (not a new concept) and this "disruptor" 
 pattern..
Key differences with a typical lock-free queue:
But for start I'd define it is a framework for concurrent processing of a stream of tasks/requests/items on a well structured multi-staged pipeline.
An excellent one sentence description!
 [snip]
 There is also highly flexible (policy-based design) selection 
 of how consumers wait on data:
 - either busy _spin_ on it thus getting the highest 
 responsiveness at the cost of wasted CPU cycles
 - lazy spin (that yields) no outright burning of CPU resources 
 but higher latency
 - and even locking with wait-notify that saves greatly on CPU 
 but kills responsiveness and throughput (but gives freedom to 
 spend CPU elsewhere)

 Thanks for pointing this out.
[snip]
 Another important IMHO observation is that the order of 
 processed items is preserved* and this is interesting property 
 if you consider doing the same stages as lock-free queues with 
 a pool of consumers at each stage. Things will get O-o-O very 
 quickly.
what does O-o-O mean ? > Nick
Dec 13 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 13 December 2012 at 23:32:44 UTC, Nick B wrote:
 what does O-o-O mean ? >
Out-of-order. David
Dec 13 2012
prev sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Wednesday, 12 December 2012 at 08:09:40 UTC, Dmitry Olshansky 
wrote:
 12/12/2012 6:00 AM, Nick B пишет:
 On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
 On Monday, 10 December 2012 at 20:08:32 UTC, Andrei 
 Alexandrescu wrote:
 On 12/9/12 10:58 PM, Nick B wrote:
 [about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far 
 ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern?
Ok, does anyone consider that this pattern, though not well described, has any value ? Nick
It surely has. I'd consider http://martinfowler.com/articles/lmax.html to be quite nice description as it helped me to decipher the most of details. The paper itself lacks illustrative material, focuses too much on overcoming Java limitations and generally too terse with important (to me) details of the framework.
[Request again] Would Andre like to make any comment, especially on the martin fowler article ? Others commenting here have said that they consider that the pattern has some value ? Nick
Dec 16 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/16/12 4:28 AM, Nick B wrote:
 I'd consider http://martinfowler.com/articles/lmax.html to be quite
 nice description as it helped me to decipher the most of details.
 The paper itself lacks illustrative material, focuses too much on
 overcoming Java limitations and generally too terse with important (to
 me) details of the framework.
[Request again] Would Andre like to make any comment, especially on the martin fowler article ? Others commenting here have said that they consider that the pattern has some value ?
What I think about a paper upon first sight is unlikely to be all that insightful, and I already have a long reading list. Why do you find it so important? Are you considering proposing a pattern implementation for Phobos and would like to gauge initial interest? Thanks, Andrei
Dec 16 2012
parent "Nick B" <nick.barbalich gmail.com> writes:
On Sunday, 16 December 2012 at 14:58:46 UTC, Andrei Alexandrescu 
wrote:
 [Request again] Would Andre like to make any comment, 
 especially on the
 martin fowler article ? Others commenting here have said that 
 they
 consider that the pattern has some value ?
What I think about a paper upon first sight is unlikely to be all that insightful, and I already have a long reading list. Why do you find it so important? Are you considering proposing a pattern implementation for Phobos and would like to gauge initial interest? Thanks, Andrei
   Are you considering proposing a pattern implementation for
Phobos and would like to gauge initial interest? Yes I am interested to see if there is ommunity interest in this pattern, and also if it could in included in Phobos, some time in the future. Nick
Dec 16 2012
prev sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
 On Monday, 10 December 2012 at 20:08:32 UTC, Andrei 
 Alexandrescu wrote:
 On 12/9/12 10:58 PM, Nick B wrote:
 [about the Disruptor framework]
 Would Andrei like to comment on any of the comments so far ??
Sorry, I'd need to acquire expertise in Disruptor before discussing it. I found http://disruptor.googlecode.com/files/Disruptor-1.0.pdf quite difficult to get into because it spends the first page stating how good Disruptor is, then the next 3 pages discussing unrelated generalities, to then start discussing implementation details still without really defining the pattern. I had to stop there. Is there a more concise description of the pattern? Andrei
I have looked, but I think the answer is to this question is no. Nick
Correction. The answer to this question is actually YES. Read the martinfowler article. See the link below. see Dmitry comments below, as well as I'd consider [Dmitry comments] http://martinfowler.com/articles/lmax.html to be quite nice description as it helped me to decipher the most of details. The paper itself lacks illustrative material, focuses too much on overcoming Java limitations and generally too terse with important (to me) details of the framework. Totally agree. Nick
Dec 13 2012
parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2012-12-14 at 05:19 +0100, Nick B wrote:
[=E2=80=A6]
 Correction. The answer to this question is actually YES.
 Read the martinfowler article. See the link below.
[=E2=80=A6] Whilst the Martin Fowler article is a good one, it is an analysts perspective on it given some study. Can I suggest that people interested in The Disruptor read the material of Trisha Gee, Mike Barker, and others. They worked on the system and have done the JavaOne, Devoxxx, JAXLondon, etc. circuit making many presentation on this from the ring buffer datastructure down to how ensuring cache line coherence on the processors influenced the way they wrote their Java code to make things lock free. Trisha has now moved on from LMAX to MongoDB, so is no longer doing The Disruptor talks. but her blog is basically an index to materials. And of course The Disruptor is FOSS, the code is on GitHub for people to look at. https://github.com/LMAX-Exchange/disruptor --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Dec 13 2012