[Haskell-cafe] [ANN](and feedback request) unagi-chan: Fast and scalable concurrent queues for x86, with a Chan-like API

Brandon Simmons brandon.m.simmons at gmail.com
Tue Jul 15 22:41:12 UTC 2014

On Tue, Jul 15, 2014 at 2:44 AM, Gregory Collins
<greg at gregorycollins.net> wrote:
> On Thu, Jul 10, 2014 at 8:39 PM, Brandon Simmons
> <brandon.m.simmons at gmail.com> wrote:
>> I'm happy to finally release unagi-chan, an implementation of
>> high-performance concurrent FIFO queues that have an API very similar
>> to Control.Concurrent.Chan. You can see benchmarks and documentation
>> here:
> It's difficult to overstate how much faster unagi-chan is than
> Control.Concurrent under contention, I'm seeing >10x improvements in the 100
> readers/100 writers benchmark on this quad-core machine. I'll have to try it
> on the 8-core at work. Performance seems to be predictably fast as you scale
> the number of workers, unlike the others which asymptotically explode during
> contention. Really impressive work, Brandon.

Thanks a lot. And thank you for trying it out.

> How close is unagi-chan to being a drop-in replacement for MVar? Since this
> implementation seems to clearly be better, personally I would wonder if it
> shouldn't just replace the existing one in the standard library.

It's a drop-in replacement for all non-deprecated functions, except
for the splitting of input and output ends of the chan and the
handling of async exceptions in the reader.

I wouldn't be comfortable advocating for it as a replacement,
personally. Mostly because of a few questions and misgivings I have
about some implementation details (especially related to memory model
stuff). They're all documented in the source and I'm very comfortable
with people using it in production, but only after running the test

> Also: can you use the same technique to get a fast implementation of bounded
> queues?

There's a pretty straightforward path to at least some sort of "fuzzy"
bounded queue that just fails (rather than the writer block), which
might end up as simply a `chanSize :: InChan a -> IO Int`. Please feel
free to add to the discussion here:

Thanks again,

> G
> --
> Gregory Collins <greg at gregorycollins.net>

More information about the Haskell-Cafe mailing list