[zeromq-dev] LMAX/Distruptor code project

Daniel Cegiełka daniel.cegielka at gmail.com
Wed Aug 24 12:41:15 CEST 2011


I found a version in C++. It may be helpful in working on zeromq.

http://www.2robots.com/2011/08/13/a-c-disruptor/

code:

http://code.google.com/p/disruptor-cpp/


interesting discussion:

http://groups.google.com/group/lmax-disruptor/browse_thread/thread/4a47a0a9b5837ca2?pli=1

and blog:

http://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html

http://mechanical-sympathy.blogspot.com/2011/08/inter-thread-latency.html


Best regards,
daniel









2011/7/29 Steven McCoy <steven.mccoy at miru.hk>

> On 28 July 2011 19:43, Ian Barber <ian.barber at gmail.com> wrote:
>
>>
>> Memory management and NUMA-awareness is very difficult, ptmalloc3 is
>>> incredibly good that you don't need your own SLAB manager like GLib has;
>>> Windows equivalent is the Concurrency Runtime.  The fight is between
>>> pre-allocating a large arena and optimising that for one fast consumer or
>>> producer, and making a multi-thread friendly architecture that allows
>>> multiple threads to publish or consume.  With PGM there is a big design
>>> issue with how to handle new publishers, whether you have a bus topology or
>>> limit to one sender at a time and recycle the receive window.  It is very
>>> expensive to allocate large chunks of memory for each new receiver.
>>>
>>
>> From what I understand the dispruptor basically acts as a bus with one
>> large allocated big of memory, but once a writing process has a slot it can
>> happily write into that part of the buffer without clashing with other
>> publishers, as they attempt to pad their slots to be as cache independent as
>> possible. I believe that most of the actual entry structures are
>> pre-allocated as well, in part of avoid GC by making them very long lived,
>> again I think that reflects the nature of events they're processing.
>>
>>
> The significant design I missed first time reading is that a single
> disruptor ring can support multiple publishers.  This is an architecture I
> need to move the PGM RX window towards in order to manage a sensible memory
> overhead and support embedded environments.  It looks like a good idea for
> OpenPGM 6.
>
> The disruptors I've described are used in a style with one producer and
>> multiple consumers, but this isn't a limitation of the design of the
>> disruptor. The disruptor can work with multiple producers too, in this case
>> it still doesn't need locks.[13]<http://martinfowler.com/articles/lmax.html#footnote-multi-producer>
>
>
> --
> Steve-o
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110824/24c6ce72/attachment.htm>


More information about the zeromq-dev mailing list