Re: Locks
Re: Locks
- Subject: Re: Locks
- From: Don Quixote de la Mancha <email@hidden>
- Date: Tue, 06 Dec 2011 20:05:34 -0800
It is a common misconception that the "volatile" keyword is necessary
or even helpful to code the implements locks and atomic operations.
What you really want is a "memory barrier" that prevents the compiler
from emitting your machine code in the incorrect order, as well as
preventing microprocessors that can do out of order execution from
reordering your instructions.
If you did not have such a memory barrier, then it could easily happen
that the payload portion of your critical section is placed outside
the region that is protected by your lock.
The popular but misunderstood use of the volatile keyword is the
result of certain, specific compilers on certain specific instruction
set architectures implementing volatile variables by generating memory
barrier machine code.
It can easily happen that your lock works properly anyway, but even if
so, the use of volatile will make your code both slower and larger.
I was quite surprised at this fact myself. My bookmark for the page
where I learned all about this is on my other computer, but if I
remember correctly it was written by an Intel engineer who was one of
the developers of an Intel open source multithreaded toolkit. That
toolkit did use volatile everywhere at first, but when Intel opened
the source and so had to support ISAs other than Intels, they removed
all the volatiles and replaced them with explicit memory barriers.
Contrary to Ken Thomases' assertion, there are all kinds of reasons to
use atomic operations as locking primitives. One is that they cannot
result in process context switches; if you are certain that you will
release the lock quite quickly, it is a whole lot faster, and uses
less memory, to use atomic arithmetic.
I'll send you my bill in the mail,
Don Quixote
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
References: | |
| >Locks (From: koko <email@hidden>) |
| >Re: Locks (From: Conrad Shultz <email@hidden>) |
| >Re: Locks (From: koko <email@hidden>) |
| >Re: Locks (From: "Stephen J. Butler" <email@hidden>) |