• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Locks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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>)

  • Prev by Date: Re: Locks
  • Next by Date: Re: Locks
  • Previous by thread: Re: Locks
  • Next by thread: Re: Locks
  • Index(es):
    • Date
    • Thread