How does thread locking work -on a high level- in the context of multiple core?

I am trying to understand multi-threading, and thread safety. Java obviously has keywords such as Synchronized to achieve that.

However, consider this scenario.

Let's say our CPU has multiple cores, so can we can execute more than one instruction at a time. So, if the instruction to obtain lock in executed -in parallel, simultaneously- on multiple cores for multiple threads, how will that work -at a high level-?

The point of a JVM is: It doesn't matter how it works, just that it works. Specifically, that the JVM guarantees no two threads can both enter a synchronized (x) {} block where x is a reference to the same java object.

There are various ways that hardware handles this.

One is CAS operations (Compare-And-Set). A CAS operation works like this:

Given CAS(memLoc, 5, 20);

• Read the value at memory address x. IF it is '5', update it to '20' and return true. Otherwise, do not change it, and return false.

Various CPUs natively support CAS operations. At the CPU level, the CAS operation is conveyed to the thing that actually locally controls that memory (i.e. if there is a separate memory controller, the CAS instruction is sent to it, too), which in the end is a small but crucial single-system bottleneck (no risk of 2 cores simultaneously doing the thing, because it's not a CPU core that does this, it's the memory controller).

If CAS is available, stuff like this is simple. For example, we can give all objects a separate 64-bit field value, and we have a single 64-bit 'thread ID' counter. Then we modify a few basics in the JVM:

• Whenever a new thread is made, we have a loop that works like this:

int threadId = -1;
while (true) {
  int currentThreadId = read(globalThreadIdCounterMemLoc);
  threadId = currentThreadId + 1;
  if (CAS(globalThreadIdCounterMemLoc, currentThreadId, threadId)) break;
}

return createNewThreadWithId(threadId);

This ensures every thread has a guaranteed unique ID. Once all threads have a unique ID:

• Add a threadOwner field to all objects.
• Implement synchronized as something like:

// an owner id of -1 means: Unowned.
public void jvmSynchronizedImpl(Thread owner, Object lockObj) {
  while (true) {
    boolean lockAcquired = CAS(lockObj.threadOwner, -1, owner.threadID);
    if (lockAcquired) return true;
  }
}

Obviously it doesn't work that simply - waiting to acquire a lock does not 'busy-wait' (where the CPU fans start blasting and your power usage goes way up because the CPU is actively and continuously checking the value; if the lock isn't available, the system waits).

Even if CAS is not available, CPU cores have LOCK instructions. For example, the x86/x64 architecture has a 'lock' modifier; it modifies any opcode that read-modify-writes memory. Such as an INC instruction (which needs to read a value from a location, increment it by 1, and write it back). If the opcode has a lock flag on it, the CPU ensures exclusive ownership of the relevant data. We just kicked the can down the road:

• How does a JVM implement locking? By relying on the CPU to do it.

Which just means we now ask: ... so, how does a CPU do it?

And the exact same rule applies: It does it. The docs spell out precisely what is guaranteed and what isn't - the CPU you buy today might implement the 'deal' as spelled out in the specs completely differently from another.

But, generally, with similar CAS-like mechanics on a shared register that all CPU cores can see. Or, it just locks a bus (and how does that work - oof, it's turtles all the way down: The bus has some specification that guarantees that if you do X and Y, then you get synchronicity guarantees, and does not spell out how it does that).

NB: CAS is sometimes called test-and-set. You might want to read the wikipedia page on test-and-set, which also covers hardware implementations. As I showed at the top, CAS is a really useful in-between: It's easy to understand, generally easy to implement by the 'lowest level thing in the hardware', and it is easy to convey (just 3 values: Location, Expected Value, and New Value - with a single bit to be returned by the operation). With CAS in your arsenal, writing more complicated synchronicity systems is easy (such as java's synchronized, but also things like AtomicInteger's incrementAndGet() which is considerably faster than using synchronized to get a consistent multi-core capable atomic incrementer). Hence why CAS is usually the solution used when all you can really do is ask the underlying whatever-it-may-be to provide you with the tools you need to make synchronicity promises. Hence, java code asks the JVM for CAS. The JVM asks the OS. The OS asks the CPU. The CPU asks the memory controller. The memory controller can actually natively implement the construct.

Important footnote: As I said at the top, this is just one way that a JVM could implement this stuff. You cannot rely on a JVM actually doing it this way, it might use completely different systems instead. "I want to know how it works" is not a particularly useful way to try to wrap your head around concurrency, because any single answer is by definition non-general (does not apply to all JVMs and all situations). The Java Memory Model section of the JVM spells out all the guarantees you do get, and if you write code that relies solely on those guarantees, your code is correct. If you rely on things you have reliably observed but which the JMM doesn't guarantee, you have a very very nasty thing: A bug in your code, that you cannot possibly test for. Your code will work fine today, and tomorrow, but next week it starts failing. Or it works for you but fails on tuesdays. Or it works for you but not for your important customer. And so on.