Am 26.04.2017 um 05:34 schrieb Doug Hill <[email protected]>: > I used to have weird multi-threaded strangeness with non-atomic properties. I > would see evidence of different threads having different values of properties > when it’s clear, by knowledge of the algorithm of my code, that they > shouldn’t. This different thread visibility drove me nuts to track down. > Adding the atomic attribute cleared up this problem.
atomic doesn't even help much with that. It only makes sure that the pointer is written atomically by using a spinlock. To be honest, this is even unnecessary: Pretty much all modern architectures allow writing a pointer atomically. The only difference is the memory barrier as a side effect of the spinlock. But you shouldn't rely on this anyway and add your own memory barrier if you need one. > However, I think the problem that was solved by switching to an atomic > property wasn’t just because the accessor code was acquiring a lock. My > theory is that because the atomic accessor code includes a lock (pthread spin > lock to be specific) atomic properties also include a memory fence because of > the pthread implementation. I belive this fence is what fixed the > multi-threaded property visibility problems I saw. Yes, much more likely :). > Memory fences can slow the entire processor since every core has to wait for > the fence to complete becfore it can access a cache line. This can kill > heavily optimized code blocks. Unfortunately, you have one on every release call. Only the retain can be done relaxed. > While I think the writeup has merit, there are many things going on under the > hood for atomic properties that can definitely affect performance. It’s well > discussed on this list and other sources on the internet that accessing > atomic properties in tight loops can kill performance. If you have tight loops, why not just use the ivar instead? That way you avoid all the overhead you can avoid (well, except the non-fragile ABI, which still adds an extra level of indirection). > Calling pthread spin lock code will definitely do that. Switching to a > non-atomic property will improve the speed of those loops. The default retain / release implementation also uses a spinlock, though. Not sure if NSObject somehow overrides that - the code isn't open and I was too lazy to disassemble :). In ObjFW, OFObjects just have a struct in front of the actual object that contains the reference count and a few other things. -- Jonathan _______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
