tag:blogger.com,1999:blog-5560209661389175529.post6782173680429554585..comments2021-11-26T19:34:10.855+00:00Comments on Mechanical Sympathy: Disruptor 2.0 ReleasedMartin Thompsonhttp://www.blogger.com/profile/15893849163924476586noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-5560209661389175529.post-27418525863940318592017-07-25T08:21:21.959+01:002017-07-25T08:21:21.959+01:00That's a "how long is a piece of string q...That's a "how long is a piece of string question". Every application is different and you have the whole context of your application to consider plus what garbage collector, JVM, OS, hardware, etc. you are running on. There is no reasonable answer to that question.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-8484847997351241142017-07-24T23:15:26.890+01:002017-07-24T23:15:26.890+01:00Hi Martin,
What should be the duration of a minor ...Hi Martin,<br />What should be the duration of a minor GC for a trading application using the disruptor based on industry standards.<br /><br />Anonymoushttps://www.blogger.com/profile/14793355292882033653noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-46256254117162400462013-10-20T18:16:49.540+01:002013-10-20T18:16:49.540+01:00It often does in my day job but then I'm often...It often does in my day job but then I'm often dealing with fast or efficient processing of data.<br /><br />Most programmers do not need very detailed knowledge everyday but an appreciation of mechanical sympathy really helps build reasonable efficient software that is also more robust. Being robust is often more important than outright performance. Driving the platform with understanding leads to less surprises and edge cases which make software fragile.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-4033638614343914012013-10-20T17:44:23.214+01:002013-10-20T17:44:23.214+01:00HI Martin,
I went through couple of posts in your...HI Martin,<br /><br />I went through couple of posts in your blog.<br />I am a coder myself.<br />I am just wondering does such deep knowledge of hardware is really required to code in our daily requirements(day job).<br />Pardon my ignorance.<br /><br />Abhi Anonymoushttps://www.blogger.com/profile/13797823134112342051noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-86125723947788612892011-11-25T11:16:05.503+00:002011-11-25T11:16:05.503+00:00David,
The JVM/JIT is able to optimise and in the...David,<br /><br />The JVM/JIT is able to optimise and in the case of x86 the AtomicLong.lazySet() is simply a software, rather than hardware, memory barrier. On other platforms it may need a hardware memory barrier/fence, e.g. ARM.<br /><br />StoreLoad semantics are the ones you really need a memory barrier on x86 for otherwise the likes of the Dekker algorithm cannot work.<br /><br />The "issue" with the volatile keyword is the semantics are defined for the Java Memory Model regardless of underlying hardware. An example where on x86 it costs more than it should, is the cost of creating an object with a volatile field because the JVM will emit a "LOCK ADD 0" for the memory barrier. This, in my opinion, should be treated like final and not needed if the this reference does not escape during construction.<br /><br />Martin...Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-91331059514306724252011-11-25T09:23:35.454+00:002011-11-25T09:23:35.454+00:00Martin,
In the memory barrier section you mention...Martin,<br /><br />In the memory barrier section you mention that on x86/x64 you're able to avoid the use of volatile due to the memory semantics of the x86 being strong enough to enforce the guarantees you need. You also state that on other architectures that this may not be the case and YMMV.<br /><br />Shouldn't it be the case that the JVM/JIT is able to optimise away the additional instructions for volatile on x86 because it knows it 'is' an x86/x64 JVM so it knows implicitly the underlying memory semantics.<br /><br />On other architectures it should also do the correct thing (optimising away or adding fences as necessary). This is how the GCC memory barriers work on Linux, on some architectures they are no-ops on others they add fence instructions.<br /><br />Is this is a case where the JVM implementation is not quite as we'd like it to be? Or are there other subtleties which mean that the JVM is not able to optimise away the volatile keyword?<br /><br />Regards<br />DavidDavid Hortonhttps://www.blogger.com/profile/13905138566602021377noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-44945566987412877792011-09-16T08:32:46.729+01:002011-09-16T08:32:46.729+01:00Martin,
I must admit, I've not had the chance...Martin,<br /><br />I must admit, I've not had the chance to play with it, just read the doc, and got the impression that it was a new idea! :) Wasn't meant as a trolling attempt... <br /><br />As to the open implementation - that's true, I did some research in this space before having to do my own implementation late last year, the article linked above gave me the starting point.<br /><br />I will download this and test it out, I'd like to see how my implementation stacks up against it.. :)<br /><br />Nim.thenimhttps://www.blogger.com/profile/11634861725580935958noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-38412488809962503012011-09-15T11:27:38.506+01:002011-09-15T11:27:38.506+01:00Thenim,
The idea of using ring buffer has been ar...Thenim,<br /><br />The idea of using ring buffer has been around a long time and often used in operating systems and network devices.<br /><br />There is nothing special about the Disruptor other than to bring together a group of concepts and implement it well.<br /><br />One part I've not seen done elsewhere is the ability to construct dependency graphs between event processors like the Disruptor can with the SequenceBarriers. However I'd not be surprised if someone else has done that before.<br /><br />As to the implementation, I've not seen anyone publish an implementation like the Disruptor and get anywhere near the same performance results.<br /><br />Martin...Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-26112793659278175052011-09-15T11:11:30.050+01:002011-09-15T11:11:30.050+01:00Hi guys, interesting work, however I would like to...Hi guys, interesting work, however I would like to point out that this concept is not new, see link: http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txtthenimhttps://www.blogger.com/profile/11634861725580935958noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-77477082741393594862011-08-30T11:42:11.655+01:002011-08-30T11:42:11.655+01:00I for one preferred the usage-agnostic nomenclatur...I for one preferred the usage-agnostic nomenclature used previously rather than the event handling terminology adopted here. While event handling is a very common scenario for using the disruptor there are many others that are no less plausible e.g. command handling (Checkout the AxonFramework for instance). It's not every intuitive be talking about events when you are processing commands. The other name and api changes are very welcome however.Jimithttps://www.blogger.com/profile/03982018547772077835noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-73638365229974044712011-08-30T11:30:37.551+01:002011-08-30T11:30:37.551+01:00Huxi,
There is not an official Maven artefact for...Huxi,<br /><br />There is not an official Maven artefact for the Disruptor yet. We plan to add one soon.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-48228031334165253322011-08-30T11:15:20.821+01:002011-08-30T11:15:20.821+01:00"Dave Dice at Oracle has blogged on the subje..."Dave Dice at Oracle has blogged on the subject so I live in hope"<br /><br />An issue has been filed:<br /><br />http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7023898<br /><br />Best,<br />IsmaelIsmael Jumahttps://www.blogger.com/profile/17398483226873559286noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-25546669938073459712011-08-30T10:15:32.648+01:002011-08-30T10:15:32.648+01:00I just found org.axonframework.com.lmax:disruptor:...I just found org.axonframework.com.lmax:disruptor:2.0 in the central maven repository but http://code.google.com/p/disruptor/issues/detail?id=2 is still open.<br /><br />Is this an official artifact and the issue simply isn't updated, yet?huxihttps://www.blogger.com/profile/03185448440798423588noreply@blogger.com