CoralQueue is a ultra-low-latency lock-free and garbage-free queue for inter-thread communication. It can be defined as a batching queue backed up by a circular array (i.e. the ring buffer) filled with pre-allocated transfer objects which uses memory-barriers to synchronize producers and consumers through sequences. Fortunately you don’t have to understand all its intrinsic details to use it. In this article we show how to use CoralQueue to send messages from a producer thread to a consumer thread in a very fast way without producing any garbage. Continue reading
CoralQueue
|
CoralQueue is a ultra-low-latency, high-performance, lock-free, garbage-free, concurrent queue, demultiplexer, multiplexer, mpmc queue and splitter. It uses memory barriers instead of locks to allow Java Threads to exchange messages in under 15 nanoseconds with top throughput of 97 million messages per second.
|
Demultiplexing with CoralQueue for Parallel Processing
In this article we examine how CoralQueue implements a demultiplexer, in other words, a one-producer-to-multiple-consumers queue. We also present throughput numbers for the three types of implementations supported: Atomic, CAS and modulus. Continue reading
Multiplexing with CoralQueue
In this article we analyze how CoralQueue implements a multiplexer to allow multiple producers to send messages to a single consumer. We then present the throughput numbers for different set of configurations with different set of cpu cores. Continue reading
Multiple-Producers to Multiple-Consumers Queue
In this article we give an example of how to use the MpmcQueue so you can transfer messages between any number of producers and consumers through a lock-less concurrent queue. Continue reading
Multicasting with CoralQueue through a Splitter
In this article we show how to use CoralQueue to multicast/broadcast the same message to multiple consumers so each consumer receives and processes all messages. We also present throughput numbers for different configurations, each one using a different set of cpu cores. Continue reading
Inter-Process Communication with CoralQueue
CoralQueue is great for inter-thread communication, when both threads are running in the same JVM. However it also supports inter-process communication (IPC) through a shared memory mapped file so that two threads running on the same machine but on different JVMs can exchange messages. This is much faster than the other option which would be network access through loopback. In this article we will examine how this can be easily done and present the benchmark numbers for IPC. Continue reading
Thread Concurrency vs Network Asynchronicity
In this article we study two different ways of handling client requests that involve a blocking operation: multithreading programming through concurrent queues and asynchronous network calls through distributed systems. Continue reading
Architecture Case Study #1: CoralReactor + CoralQueue
You need a high throughput application capable of handling thousands of client connections simultaneously but some client requests might take long to process for whatever reason. How can that be done in an efficient way without impacting other connected clients and without leaving the application unresponsive for new client connections? Continue reading
CoralQueue Throughput Test Explained
In this article we will present the benchmark test used by CoralQueue that shows a throughput between 55 and 65 million messages per second without hyper-threading and between 85 and 95 million messages per second with hyper-threading. If you are interested in the CoralQueue Getting Started article, you can check it here first. Continue reading
CoralQueue Performance Numbers
In this article we present CoralQueue performance numbers for four different scenarios: message-sender latency, message transit latency, message-sender throughput and message transit throughput. The standard scenario of one producer (message-sender) and one consumer (message-receiver) is used with two possible setups: producer and consumer pinned to the same core (hyper-threading) and producer and consumer pinned to different cores (no hyper-threading). Continue reading