abc-arbitrage / disruptor-cpp Goto Github PK

hello !

this is very nice and useful project thank you for making it available.

Sadly it doesn't build on aarch64 architecture (mac M1) as it replies on some assembly instructions which are not supported.

e.g

$ make
Scanning dependencies of target DisruptorStatic
[ 2%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/BasicExecutor.cpp.o
[ 4%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/BlockingWaitStrategy.cpp.o
[ 6%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/BusySpinWaitStrategy.cpp.o
[ 9%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/FixedSequenceGroup.cpp.o
[ 11%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/ProcessingSequenceBarrier.cpp.o
[ 13%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/ProducerType.cpp.o
[ 15%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/RoundRobinThreadAffinedTaskScheduler.cpp.o
[ 18%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/Sequence.cpp.o
[ 20%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/SequenceGroups.cpp.o
[ 22%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/SleepingWaitStrategy.cpp.o
[ 25%] Building CXX object Disruptor/CMakeFiles/DisruptorStatic.dir/SpinWait.cpp.o
/tmp/ccVC3BXq.s: Assembler messages:
/tmp/ccVC3BXq.s:119: Error: unknown mnemonic rep' -- rep'
/tmp/ccVC3BXq.s:220: Error: unknown mnemonic rep' -- rep'
/tmp/ccVC3BXq.s:241: Error: unknown mnemonic rep' -- rep'
make[2]: *** [Disruptor/CMakeFiles/DisruptorStatic.dir/build.make:193: Disruptor/CMakeFiles/DisruptorStatic.dir/SpinWait.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:152: Disruptor/CMakeFiles/DisruptorStatic.dir/all] Error 2
make: *** [Makefile:163: all] Error 2

I don't expect you to fix this as you obviously made this implementation for your use case with low latency in mind - though may be you could still consider adding a similar fix as in this similar case?

nats-io/nats.c#87

Regards, Roman

What i want to do is control which eventhandler gets to use which cpu core, so I can disable hyperthreading on a few cores and enable it on another.

Thanks for making this available. Is this used in production, or intended to be "production ready"?

See #10 which fixed this issue for SingleProducerSequencer but the same issue is still present in MultiProducerSequencer

I'd like to put vector, variant, unique_ptr, string, Eigen::VectorXf into the queue, is it possible?

Hey,

thank you for the port!
I was comparing to java version, and feels MultProducerSequencer.setAvailable() has different visibility properties?

void setAvailableBufferValue(std::int32_t index, std::int32_t flag)
{
    m_availableBuffer[index] = flag;
}

vs https://github.com/LMAX-Exchange/disruptor/blob/95c705f60c1833b07f1fed6e08a08d7bee7f0971/src/main/java/com/lmax/disruptor/MultiProducerSequencer.java#L235

    private void setAvailableBufferValue(final int index, final int flag)
    {
        AVAILABLE_ARRAY.setRelease(availableBuffer, index, flag);
    }

setRelease (the docs say) is roughly equivalent to m_atomic_int.store(..., std::memory_order_release);

the cpp version does not have the release memory semantics? I cant see why its not needed in c++ version, do you know?

How it can be lock-free when you use condition_variable and unique_lock?

I am trying to compile with gcc, but I am unaware of what linker flags I need to add it to my project.

Thanks

Hi everyone,
First of all, thank you very much for this library,
however i'm a bit lost on this one, does anyone know what is the cleanest way to install this library with cmake?

https://github.com/Abc-Arbitrage/Disruptor-cpp/blob/master/Disruptor/EventPoller.h#L39 could be trivially refactored to take a forwarding reference as the eventHandler instead of a std::function. This would eliminate the potential for memory allocation when the std::function is constructed and the virtual call when the eventHandler is invoked.

Disruptor/EventPoller.h:57:37: runtime error: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long

Java guarantees deterministic overflow behavior for signed integers but C++ doesn't resulting in undefined behaviour in various locations throughout the code - the above is only one example.

Hi,
It not work on CentOS 7. Any plan of this?

Are there benchmark results on how consistent the latency is compared to LMAX Disruptor Java?

Otherwise it's possible to get a deadlock where the producer is waiting for >N free slots which will never become free.

e.g.

https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/SingleProducerSequencer.java#L119
vs
https://github.com/Abc-Arbitrage/Disruptor-cpp/blob/master/Disruptor/SingleProducerSequencer.h#L89