In my studies of the IMemory­Buffer interface, I found three implementations of that interface in the Windows Runtime.

• Windows.Foundation.MemoryBuffer, obtained from Buffer.Create­Memory­Buffer­Over­IBuffer().
• Windows.Graphics.Imaging.BitmapBuffer, obtained from Software­Bitmap.Lock­Buffer().
• Unnamed class obtained from PerceptionFrame.FrameData.

We also wrote our own fourth implementation, which we called Custom­Memory­Buffer, that lets you turn any block of memory into a Memory­Buffer.

All four of them behave differently. Let’s compare.

All happy memory buffers look alike. Each unhappy memory buffer is unhappy in its own way.

The standard Memory­Buffer has the problem of not being thread-safe. If you call Close at the same time as Create­Reference, you may experience use-after-free bugs. And if you call Close twice simultaneously, you can add to your woes null pointer crashes, over-release of the underlying IBuffer, and double-raising of the the Closed event, depending on exactly how the race plays out.

All four implementations agree that if you call Create­Reference on a closed IMemory­Buffer, you get an “empty reference”. An empty reference is one that protects no memory. If you ask for the buffer of an empty reference, you get a null pointer and a size of zero.

In all of the implementations except Frame­Data, empty references raise the Closed event.

The Bitmap­Buffer‘s memory buffer reference raises the Closed event only on an explicit call to Closed. The others raise the Closed event either on explicit closure or when the last reference is released. This means that Bitmap­Buffer reference’s Closed event is even more unreliable than the Closed event already is by its nature.

The Memory­Buffer and Frame­Data ignore attempts by the Closed event handler to extend the reference’s lifetime. The biggest consequence of this is that the Closed event in those implementations will corrupt memory if consumed from a GC language. The Bitmap­Buffer sneakily passes this test because it is masked by the other defect of simply not raising the Closed event in the dangerous scenario in the first place.

The Bitmap­Buffer and Frame­Data raise the Closed event after freeing the memory, which means that the event is useless for triggering cleanup: Since you are told that the memory has been freed only after it happened, all you’re really learning is that “Oops, you already corrupted memory.”

The Frame­Data has the bonus insult of passing you an IMemory­Buffer­Reference in the Closed handler that cannot be used! Any attempt to obtain the buffer’s capacity or pointer will hang. (That’s because it raises the Closed event while still holding its internal lock. Calling to outside code while holding a lock is a bad idea for reasons like this.)

Our Custom­Memory­Buffer tries to avoid all of these little defects.

But what if you are forced to use one of the other three implementations of IMemory­Buffer, or some other fifth implementation from an external source that isn’t even on the list. Seeing as the first three attempts at implementing IMemory­Buffer all failed in different ways, what confidence do you have that an unknown implementation will be well-behaved?

We’ll solve this problem next time. The answer is right under our nose.