Re: Locks
Re: Locks
- Subject: Re: Locks
- From: koko <email@hidden>
- Date: Tue, 06 Dec 2011 21:20:22 -0700
My apologies for posting to the Cocoa list.
It was just a silly mistake and will never happen again.
Thank for pointing out my error, Ken. We need good policemen to keep Apple Developer lists pure!
And now I see that I have started a real problem as Don Quixote de la Mancha is discussing non-Cocoa issues on the Cocoa list.
I must retire now, to sleep, to dream, to awaken to a fresh tomorrow aware of my onerous ways.
-koko
On Dec 6, 2011, at 9:05 PM, Don Quixote de la Mancha wrote:
> 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
>
_______________________________________________
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>) |
| >Re: Locks (From: Don Quixote de la Mancha <email@hidden>) |