![]() Memory barrier operations are usually also operations that ensure cache synchronization among all threads/cores/CPUs in the system.Īnd to add something really useful here as well, this is how you can ensure that setting a boolean value is atomic and acts as a memory barrier in 2020 using C11 which will also work in Obj-C Code: #import Even after you set a BOOL to YES, some other thread may still see it as NO for a limited amount of time. Explicit atomic instructions as well as locks, mutexes and semaphores are usually memory barriers, that means they instruct the compiler and CPU to not move instructions located before that operation beyond it and not move instructions located after that operation before it (it's a hard border, that instructions may not pass).Īlso cache consistency is not guaranteed. The compiler and CPU are free to shuffle these three instructions around as desired since they don't depend on each other. The fact that b is YES does not mean that a is 10. There is no guarantee that instructions are executed in that order. The compiler and the CPU may reorder instructions around a BOOL write: a = 10 ![]() Note that atomic is not the same as thread-safe. ) guarantee that writing a variable of int-size is always atomic, whether other sizes are atomic depends on the CPU. On other systems it depends on your compiler used and how BOOL is defined for that platfrom. The Obj-C language makes no such guarantee, though. BOOL is uint32_t on PPC systems and char on Intel systems and writing these data types is atomic on their respective systems. It is if your hardware is a Macintosh running macOS. Is BOOL read/write atomic in Objective C? ![]() It would only play a role if two threads write a different value to the same memory location or if one thread writes to it while another one is reading from it. If to threads write the same value to the same memory location, the memory location will have that value, whether that is atomic or not plays no role. What happens when two threads set a BOOL to YES "at the same time"? Not be used on anyway (microcontrollers with or without some micro OS are C & assembly territory I suppose. Would not be atomic on some narrow bus architectures objective C would BOOL variables (which do not obviously support atomic/nonatomic decorators.Who can't tell a float from a double, or do you? It's idiotic and wasteful, you don't want to be a clone of a Java programmer, you most definitely should not use 4 byte properties to store booleans into.memory barriers are orthogonal to atomicity.On all HW iOS and macOS intrinsically supports. you can declare BOOL properties as atomic and it won't cost you a dime.that would raise to the challenge of disassembling synthesized BOOL getter and setter for atomic/nonatomic cases to see what's the difference. I'm sure there are hardened individuals on s.o. ![]() ![]() Sacrifice the futureproofing of your code nonatomic is fine for this use case. The code would not be portable to Road Light OS but if you can You could just as well use nonatomic BOOLs in a situation that calls for atomic BOOLs. On an IBM microcontroller that has 5 bit wide bus to send 10 bit bytes over So, unless Apple comes out with Road Light OS running While objective c does not guarantee that BOOL properties declared as nonatomicĪre in fact atomic I'd have to guess that the hardware you mostĬare about (all iOS and macos devices) have instructions to perform byte reads and stores atomically. I would have to diverge from the accepted answer. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |