Introducing Collage: Barrier

While I personally think that barriers are an anti-pattern, they have exactly one valid use case in my line of work — as swap barriers synchronizing the display of a new frame across multiple segments of a display wall or immersive installation.

In an ideal work, swap synchronization would be done using hardware support. Equalizer supports this for nVidia G-Sync, but I haven’t seen many installations using hardware swap synchronization. First, it’s expensive since you need a professional grade card with a special synchronization board. So lower cost installations such as display walls typically don’t even have the hardware. Installations which need the frame synchronization, such as active stereo setups, oftentimes only use the frame (retrace) synchronization and use a software barrier for swap synchronization. The reason is that getting hardware swap synchronization running is such a mess due to driver issues that most people don’t bother. For these reasons, Equalizer both supports hardware and software swap synchronization. The software synchronization used a co::Barrier.

Back to the Collage barrier: Once it is set up, the only call needed is enter, which will block until the height has been reached.

Barriers are versioned, distributed objects. Any process can set up a barrier, register it and communicate the barrier identifier and version to all users of the barrier. The users map, sync and enter the barrier. Since it’s versioned, the master instance can be committed any time, and enter requests are versioned, that is, a barrier operation for an old version will be finished before the enter requests for the new version are processed.

The protocol right now is very simple, a master instance simply tracks enter requests until the height is reached and then unlocks all users. While there are other algorithms which use optimized tree structures or broadcast to reduce the latency, we haven’t seen the need to implement a more complex algorithm.

Introducing Collage

Collage evolved from the Equalizer network library. Now it’s used by a few other projects as well, and I’ve been mentioning it quite a few times on this blog already.

Looking back over the last seven years of Equalizer, Collage has received by far the largest investment in manpower compared to all the other components. It seems innocent enough, but trust me, getting a distributed network library right and bug free is no small task. On the one hand, the ‘fun’ implementation of the Windows IP stack (WSASYSCALLFAILURE and stack corruptions) took a lot of debugging to get going, and on the other hand advanced features such as InfiniBand support (thanks Dardo!) and fast, reliable multicast are no small task to implement.

What’s wrong with boost::asio?

Nothing. It provides about the same functionality as co::Connection and co::ConnectionSet. We use it as the UDP backend for the RSP multicast implementation. It wasn’t around when I started eq::net, which became Collage. We’ld love to replace co::Connection and co::ConnectionSet with it, but the effort of porting the RDMA and RSP connections to asio has prevented this so far. Ultimately Collage tries to provide higher level abstractions.

What’s wrong with 0MQ?

Again: Nothing. It provides higher level abstractions then asio. It’s less likely that we’ll use it as the backend for Collage, since some of the design decisions are somewhat different from what Collage is doing.

So, what’s next?

Collage, similar to Lunchbox, aims to provide high-level abstractions. Similarly to the introducing Lunchbox series, I’ll present them over the next few weeks. In the same timeframe, we are planning to separate the Equalizer and Collage projects as well as to define and document the ‘1.0’ Collage API.

For now, you can find a technical overview presentation on the Collage website. Enjoy!