Re: NSLock locking order;
Re: NSLock locking order;
- Subject: Re: NSLock locking order;
- From: Shawn Erickson <email@hidden>
- Date: Mon, 14 Nov 2005 09:01:48 -0800
On Nov 14, 2005, at 8:46 AM, Alastair Houghton wrote:
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.
True true. I was running with the assumption that "/* Other work...
*/" was doing function calls / messaging. :)
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).
*nod*
I just like to speak up on the use of volatile since I have seen it
to often used for the wrong reasons and with the wrong assumptions
behind what it does and doesn't do for you.
Cheers,
-Shawn
_______________________________________________
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