macOS Thread safety for non-object variables

[iSee]

Well, technically, there is no guarantee that the assignment to _object is atomic. Practically speaking it might be because there is probably a single instruction before which _object is null and after which it is pointing to a valid object. It's not a good idea to make assumptions, though, because bugs creep in. Imagine if this was compiled under Objective-C 2.0 and _object was a garbage collected object reference; A bunch more than simply copying a value is going on in that assignment.

Anyway, to be safe, you should also synchronize -getObject:

- (id)object;
{
	id theObj;
	@synchronized(self)
	{
		theObj = _object;
	}

	return theObj;
}

Another option that might be higher performance is to use the explicit atomic operations. I haven't used these on Mac, so I'm not sure exactly how to do this, but you can find info in the docs. However, if the overhead of synchronization is causing performance problems, its usually better to redesign things to require less synchronization than it is to optimizing the sync operations themselves. (Also, atomic operations can have significant overhead themselves on multiprocessor/core systems, anyway, so again, it's best to reduce the need for synchronization.)

64-bit vs. 32-bit shouldn't make a difference.

 

[lazydog]

I'm probably going to be of no help to you, but I think you can only say method object is thread safe only if you know for definite that pointers are atomic read/write on the system that your program is running on.

On my G4 system, sig_atomic_t is defined as int, ie reading or writing an int is atomic, but I couldn't say for sure if this also applies to pointers even though they are the same size as ints, ie 32 bits. I would imagine it does though. Not sure about 64bit systems, you would need to look at the definition of sig_atomic_t.

b e n

 

[Nutter]

Thanks guys.

Imagine if this was compiled under Objective-C 2.0 and _object was a garbage collected object reference; A bunch more than simply copying a value is going on in that assignment.

Actually, it was something I read in the Leopard docs in reference to GC that made me wonder about this whole subject again. Obviously the docs are under NDA, but if you have Leopard, take a look in the "Properties" section of the Objective-C 2 guide, and see what it says about the cost of atomic property setting under GC vs. reference counting.

I could use OSAtomicCompareAndSwap32Barrier() (or OSAtomicCompareAndSwap64Barrier() if in 64-bit mode), but I'm not entirely happy about the idea of typecasing from a pointer to an int. Isn't that supposed to be discouraged?

On my G4 system, sig_atomic_t is defined as int, ie reading or writing an int is atomic, but I couldn't say for sure if this also applies to pointers even though they are the same size as ints, ie 32 bits. I would imagine it does though. Not sure about 64bit systems, you would need to look at the definition of sig_atomic_t.

Hm, sig_atomic_t is defined as an int for i386 as well. I think it's the same on 32-bit and 64-bit systems. (After all, an int is the same length on both ... but a pointer isn't.)

 

[Nutter]

Aha, I found something interesting:
http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html

In practice, you can assume that int and other integer types no longer than int are atomic. You can also assume that pointer types are atomic; that is very convenient. Both of these are true on all of the machines that the GNU C library supports, and on all POSIX systems we know of.

Ok, I'll stop now.

Conclusion: Writing to integer and pointer types is atomic on current architectures. However, this is implementation-dependent, so code that relies on this assumption will be somewhat fragile.

 

[devman]

Actually, it was something I read in the Leopard docs in reference to GC that made me wonder about this whole subject again. Obviously the docs are under NDA, but if you have Leopard, take a look in the "Properties" section of the Objective-C 2 guide, and see what it says about the cost of atomic property setting under GC vs. reference counting.

If you have multiple atomic properties that are logically grouped you would make them non-atomic and put a lock (or similar) around the group of them yourself. Thus avoiding the cost of the spinlock per-property.

 

[savar]

Aha, I found something interesting:
http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html

Conclusion: Writing to integer and pointer types is atomic on current architectures. However, this is implementation-dependent, so code that relies on this assumption will be somewhat fragile.

That document is from 1994!

In general I would *never* assume that something is atomic. As another poster mentioned, it's brittle. Even if it does work today on your machine, how do you know it will work tomorrow on somebody else's maching? These are the most insidious bugs, because they work their way in and apparently seem to work for years before they mysteriously fail.

On a power mac, for example, there are seemingly simple assignments that compile to multiple instructions. See this, e.g.

http://www.ibm.com/developerworks/linux/library/l-ppc/