3 ms·

As soon as you yield, things become non-deterministic, so aren't compatible with real-time requirements. If you have 50 threads trying to access the same thing

As soon as you yield, things become non-deterministic, so aren't compatible with real-time requirements. If you have 50 threads trying to access the same thing then what you have is a software design problem. Most synchronization should be done through spsc queues, which are easy to make lock-free (or even wait-free) and efficient, so long as you're aware of how to deal with backoff on the producing side and idle work on the consuming side. The Optiver model you're describing is pretty much how I'd build any low-latency application. It doesn't really require special hardware to do these things (you can use io_uring to bypass the kernel context switches for anything). It's also much simpler than what you hint at.

benreesman 4y ago
I'm willing to accept that a London-based crypto startup (i.e. LMAX-integrated) could have a use for extreme low-latency, extreme low-variance soft-realtime C++. In the sub-mike p99 regime you probably want to keep multithreading out of it entirely in fact. Hopefully you can accept that nitpicking the use of well-tested concurrency primitives on a forum full of impressionable up-and-coming hackers is almost certainly going to create downward pressure on sensible engineering choices amongst readers of your comments.
- mgaunard 4y ago
  Have you been googling me? A few inaccuracies there ;).
gpderetta 4y ago
>As soon as you yield, things become non-deterministic, so aren't compatible with real-time requirements. SCHED_FIFO and SCHED_RR. Although linux is not really an RT OS.
- benreesman 4y ago
  Once again, exactly right. I deeply appreciate you helping to steer this little tire fire of a comment thread I seem to have created off the rocks, I meant well but it seems to have ended up as an advertisement for insane defaults. With that said, the parent seems pretty committed. And for all I know, is actually doing sub-microsecond software HFT or hard-realtime signal processing. Thread: listen to this person ^.
  - mgaunard 4y ago
    Threads can be derailed, that's usually how interesting things come up.

benreesman 4y ago

I'm willing to accept that a London-based crypto startup (i.e. LMAX-integrated) could have a use for extreme low-latency, extreme low-variance soft-realtime C++. In the sub-mike p99 regime you probably want to keep multithreading out of it entirely in fact. Hopefully you can accept that nitpicking the use of well-tested concurrency primitives on a forum full of impressionable up-and-coming hackers is almost certainly going to create downward pressure on sensible engineering choices amongst readers of your comments.

mgaunard 4y ago
Have you been googling me? A few inaccuracies there ;).

gpderetta 4y ago

>As soon as you yield, things become non-deterministic, so aren't compatible with real-time requirements. SCHED_FIFO and SCHED_RR. Although linux is not really an RT OS.

benreesman 4y ago
Once again, exactly right. I deeply appreciate you helping to steer this little tire fire of a comment thread I seem to have created off the rocks, I meant well but it seems to have ended up as an advertisement for insane defaults. With that said, the parent seems pretty committed. And for all I know, is actually doing sub-microsecond software HFT or hard-realtime signal processing. Thread: listen to this person ^.
- mgaunard 4y ago
  Threads can be derailed, that's usually how interesting things come up.