Thread Safe Circular Queue Implementation
First some style notes:


capactiy should be capacity. Spelling is important in all kinds of writing, because all writing is primarily communication, intended for humans just as much as for computers.
The entire RingBufferFree widget is unnecessary. std::unique_ptr&lt;T[]&gt; will do the right thing by default.
Temporary variables are often a code smell, if they're not serving an explanatory purpose. In the constructor, buffer_ptr is unnecessary.

explicit RingBuffer(std::size_t capacity) :
    _buffer_capacity(capacity),
    _ring_buffer_array(new T[capacity])
{}

Personally, I'd never write std::size_t, since size_t works just as well; but your mileage may vary.
~RingBuffer() {} is unnecessary; remove it.
It's unclear to me why you're using a std::unique_ptr&lt;T[]&gt; at all, when a std::vector&lt;T&gt; would work just as well.
It's odd that TryPush takes T&amp; val, instead of const T&amp; val or (better) T val or (perhaps best in this context) T&amp;&amp; val — where you move-assign either of the last two into place with _ring_buffer_array[current_write] = std::move(val);.
Likewise, in TryPop you probably ought to be moving-from the buffer element: *val = std::move(_ring_buffer_array[current_read]); 


Okay, let's go find some concurrency bugs!



Obviously you'll have problems if two different threads try to call Push at the same time (because one will overwrite the other's pushed item); and you'll have problems if two different threads try to call Pop at the same time (because both could pop the same item).

So let's assume that this is just supposed to be a single-producer single-consumer queue, and look for bugs in that scenario.



Actually, assuming it's only supposed to be single-producer single-consumer, it's pretty clean! The only potential issue I see is that if the user calls Q.Pop() on an empty queue, or Q.Push(x) on a full one, then the thread in question will busy-loop forever — or at least until some other thread manages to break in and get some actual work done. It would be significantly friendlier if you put something in the while loop's body, e.g. std::this_thread::yield() — or even better, just return false or throw QueueEmptyException() or something like that, so that the calling code can decide what it wants to do, instead of getting blocked for an indefinite amount of time.

In other words, TryPush and TryPop smell like the real primitive operations here; Push and Pop are non-primitive operations of dubious utility.