Re: NSLock locking order;
Re: NSLock locking order;
- Subject: Re: NSLock locking order;
- From: Alastair Houghton <email@hidden>
- Date: Mon, 14 Nov 2005 16:46:13 +0000
On 14 Nov 2005, at 16:37, Shawn Erickson wrote:
On Nov 14, 2005, at 8:19 AM, Alastair Houghton wrote:
/* -- Declarations (probably within an object instance) -- */
NSConditionLock *condLock;
volatile BOOL needsToStop;
In this example you don't even need to make "needsToStop" volatile.
You are calling functions / sending messages in the thread's while
loop
Am I? :-)
Actually outside of the needsToStop conditional, I wasn't, so it
*would* have been a bug to omit it. Most useful programs, however,
including Matt's I imagine, will be making function calls, in which
case you're right.
so the compiler has to assume that "needsToStop" can change as a
side effect of those. It will be reloaded from memory as needed.
You really only need volatile if the value can change, affecting
what you want to do with it, while in a block of code without any
function calls / memory barriers taking place. For example the var
is a memory mapped PCI device hardware register.
Agreed, this is all true. Personally I prefer seeing an explicit
volatile in there anyway, because it doesn't hurt performance (since
it does need reloading, whether because the compiler can't make
assumptions about function calls or for some other reason) and it
makes it obvious that the variable really does need to be reloaded,
and the code won't break if I remove a function call from the loop (I
know plenty of people who wouldn't find it obvious that deleting a
function call and replacing it with a macro or inline code could
cause the test to break).
Kind regards,
Alastair.
--
http://www.alastairs-place.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden