gavinclarke0

I fell for this. When I called adobe to complain the service rep said, in a manner not much polite than this, that "I don't believe you that you didn't know you were signing up for a year".

Looking back, I now see where I agreed, but the manner in which they attempt to deceive you is criminal.

I implemented it using generics not for performance gains but to avoid type assertions and interfaces which I find are a major source of error and side step many of the benefits of a type safe language. Any performance gains is merely a side affect.

Using atomic instructions is still generally considered lockless with the idea that since the lock is at the instruction level and thus progress can still be guaranteed it is "lockless". If this is true in practice depends on a whole host of factors.

I do not doubt majority of cases a mutex is faster/more appropriate. However the key there is looking at what m.lockslow() or unlockSlow() does which is called on lock contention. They become spinlocks that are not entirely dissimilar to my implementation.

The idea is that a lockless algorithm is trading a worse best case i.e m.lockSlow is not called for a better worse case. Again if this is true in this exact case, I am not sure as I have not benchmarked it against a naive mutex based ringbuffer.