Alert icon
We're changing our privacy policy. This stuff matters.  Learn more  Dismiss

IA Memory Ordering

Loading...

Sign in or sign up now!
10,948
Loading...
Alert icon
Sign in or sign up now!
Alert icon

Uploaded by on Feb 29, 2008

Google Tech Talks
February, 28 2008

ABSTRACT

Intel recently published more precise memory ordering principles for the
IA32 and Intel Architecture 64 (aka x86) processors. This talk discusses
the key principles embodied in this memory ordering and explains some of
the software driven motivation behind them. Along the way we discuss
issues such as publication safety and how to use the principles to
implement the memory models found in high level programming languages.
The presentation is aimed at developers of concurrent shared memory
software and will provide a presentation of the principles as well as
guidance on how to reason about them.

This is joint work with Bratin Saha and many others both inside as well
as outside Intel.

Speaker: Richard L. Hudson
Richard L. Hudson is best known for his work in memory management
including the invention of both the Train Algorithm and the Sapphire
Algorithm. Richard joined Intel in 1998 where he has worked on memory
management, concurrency, synchronization, and memory model related issues. He went to Shortridge, holds a B.A. degree from Hampshire College and an M.S. degree from the University of Massachusetts.

Category:

People & Blogs

Tags:

License:

Standard YouTube License

  • likes, 1 dislikes

Link to this comment:

Share to:
see all

All Comments (5)

Sign In or Sign Up now to post a comment!
  • @16.39 Rule (5) causal consistency:

    For Processor 1 did we mean:

    - mov [_y], 1

    + mov [_y], r1 << r1 not 1

    w/o that not sure why store(y) is causally related to r1 = load(x) in Processor 1.

  • No wonder google can put forty-minute long high quality videos on the tube...it owns it

    Interesting topic btw...

  • soy de peru esta interesante el video nos enseña mucho....

    sigue asi! chau.

  • It seems to me that the total lock ordering must impose a fundamental scalability overhead. I haven't read the paper but it seems they're saying that they will supply an actual total ordering, rather than an "as-if" ordering. Meaning that two completely independent processes will get a total ordering on their critical sections, regardless of whether they could detect that or not. It's hard for me to see how a performance impact could be avoided.

  • it would be nice to see a talk from ulrich drepper as well, if he ever did one on the topic.

Loading...

0 / 00Unsaved Playlist Return to active list
    1. Your queue is empty. Add videos to your queue using this button:
      or sign in to load a different list.
    Loading...Loading...Saving...
    • Clear all videos from this list
    • Learn more