简体   繁体   中英

Multiple threads of same process across mutiple cores

Came to know that there is a possibility of multiple threads being executed on different cores of the same cpu. So will the definition of thread context switching still remains same? I mean will the address space still shared across threads in different cores. Also will the synchronized block still remains safe from a thread running in a different core?

Yes, all modern CPUs implement Symmetric Multi Processing (SMP) systems. That is, all memory appears in the address space of all cores on all CPUs, and the same address on all cores refers to the same bytes in the memory chips.

In hardware terms this is far from ideal. Modern CPUs are not truly SMP, rather SMP is synthesized on top of a Non Uniform Memory Architecture (NUMA); different memories sit on different address buses on different CPUs (or on some architectures, different cores). Thus a core on one CPU cannot directly address memory on another CPU.

What Intel, AMD, etc have done is implemented very fast network-like communications channels between CPUs / cores. So when the core tries to access memory addresses that are not directly connected to it, it sends a request over the channel to the core which is connected to the right memory chips. That core does the look up, sends the content back across the network. There's a whole lot of traffic like this going on all the time, keeping caches up to date, etc.

This is not ideal as there's a fair chunk of silicon dedicated to running this network, transistors that might otherwise be used for implementing more cores instead.

We only do this because, back in the day, the cheap way of getting multiple CPUs working was to stick 2 chips on the same memory address / data bus. Cheap, because the hardware was cheap and multithreaded software (used to being context switched within a single CPU) didn't really notice the difference.

To begin with this wasn't too bad - memory wasn't that slow in comparison to the CPUs. However it soon became unsustainable, but by then there was far too much software in the world expecting an SMP environment (small things like all major OSes). So whilst the ideal hardware architectural shift back then would have been pure NUMA (and damn the software), the commercial reality was that SMP had to persist. Hence the emergence of interconnects like Intel's QPI, AMD's Hypertransport, etc.

The irony is that quite a few modern languages (Golang, Rust, etc) support message passing (CSP, Actor model) as part of the language. This is exactly the programming paradigm that one would be forced to adopt if the underlying hardware was pure NUMA. So there we have it; message passing paradigms suitable for NUMA machines being implemented by trendy languages on top of SMP architectures, which in turn are synthesized on top of actual NUMA hardware. If you think that's crazy, you're not alone.

You can think of QPI, Hypertransport, etc as being a bit like Ethernet attached memory, with CPUs or Cores acting as memory servers for other CPUs and Cores. Only QPI, Hypertransport are a lot quicker, and it's all hidden away from the software running on the CPUs.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM