Use the gcc built in atomic operations rather assembler code

I don't like this. My main dislike is that we start meddling with Apache released software. I think someone wants a vendor-specific change in the stack's component - they need to work with the community in question. Bigtop releases shouldn't be used as a vehicle to make changes in the upstream.

This is a slippery slope and we should use it with utmost caution: that's why I am generally against patching stuff in our releases.

Hi Konstantin Boudnik: This is not a vendor specific change, the change is picked from upstream (3.5 branch of zookeeper) . Poor wording from my side.

The patch is removing a machine-specfic and gcc-specfic assembler statement and is replacing it with a gcc specific generic atomic instruction. That's really an improvement.

Well, it is a platform specific one (poor wording on my side, I guess My point still stands: we are making decisions on what to do fix in the upstream and what not. It is fine if we decide to do in the sound mind and not simply as a one-time thing. From the historical standpoint though: we never been doing this and were steering clear of the distribution games so we can remain the only data stack 100% based on Apache genuine released. This stance could be right or wrong, but it is what it is. If we are seeing a need to change it - perhaps it is a time. But I would try to work with ZK community to incorporate the fix into their next release.

Continuing the conversation started on BIGTOP-1934, I have linked this JIRA to the appropriate ZK ticket. We clearly need to track the release of ZK 3.5 to remove this patch once it is out.

Right. Ok, to commit ?

Yup, thanks!
Also, can we get a JIRA to track down the future removal?

Committed