learned that os_unfair_lock with & was quite unsafe when used within
swift. Apparently in swift, &foo in Swift means "make a copy of foo and
pass it inout to a function, then overwrite its value with whatever
the function did to it when that function returns."
And if you're using it within a struct, it's apparently even more
dangerous. because the address of self can change from call to call
— self might not even have an address, it might be contained in
registers only.
Using NSlock will be a smidge less performant, but notably more safe.