I recently started reading about programming in Assembly. To my knowledge, in Assembly, a programmer, when storing and retrieving their variables, has to specify the address their variables are stored in from the RAM register to the CPU.
Now my question is: What if in multi threaded CPUs, two programs that a user runs and both programs tries to access the same memory address at the same time either reading or writing, what happens? How would one prevent this?
Without any further coordination, at least one writer plus one reader can result in a classic race condition.
There are a number of factors involved.
If there is only one memory location involved (a byte, or aligned word) it is possible that two threads, one writer and one reader, accesing the same location, do effectively communicate. (Alignment is usually important in the context of the professor's memory model, because unaligned data acts like two or more independent memory locations)
However, keeping within these limitations alone does not allow a generous or rich interaction between two threads.
Involve more than one memory location or more than one writer and explicit synchronization is almost certainly required.
There are various processor instructions that facilitate synchronization.
One set works like an atomic read-modify-write, and allows multiple writers to do, among other things, increment a counter without loosing any counts. These are sometimes implemented as compare-and-swap instructions. There are a number of variations, including paired insructions load-linked and stored-conditional.
There are also memory barrier instructions that tell the processor something about when and how to flush individual processor caches to common main memory.
These primitives can be used to build larger locks. Most operating systems will provide some rich thread synchronization capabilities that are in some way built on these hardware primitives.
Programming languages and operating systems expose these hardware primitives thru locking, synchronized methods & blocks, and volatile variables.
Transactions and or transactional memory is another very interesting feature having some underlying, new hardware support, but is still very new.
In most modern operating systems, user mode processes run in isolated virtual address spaces. That means that each process has a table that the processor uses to look up where a memory address generated by a running program is actually stored. Because your two programs have different tables, even if they both try to access the same address, the memory they will access will be different.
Whether it is two cpu cores or a contest between other peripherals it is certainly possible for those things to be accessing the same resource "at the same time" of course it is generally not possible to be "at the same time". The logic queues up transactions for a resource and manages them in a way that works for that resource. So they will get ordered.
It is an extremely common problem, even with a single cpu, to deal with resource sharing, been a problem since the dark ages of programming, and as such have had many solutions. There has to be hundreds/thousands of answers on this site to cover this topic. Often you rely on a test and set or other processor or peripheral feature that allows one application/task/thread to lock/reserve a resource, and so long as all the software (and/or logic) that accesses that shared resource conforms to that locking/sharing then you wont have a problem. In the old days a simple trick was to disable interrupts for a section of code for example.
In the early PC days we did have the blinky problem where cpu access to the video ram was higher priority than the video chip access to that memory and if software was accessing memory right when the video card needed it the video card would lose and get random garbage or whatever was left on the bus, who knows, the transaction would fail but the video card would still have to output a signal, so you would get bad characters blink on the screen for one refresh, if the software kept doing it then where those blinks occurred would appear random. Solution, share, software should only access video ram during a vertical retrace (or horizontal) (CRTs remember, takes a little bit of time to change the energy in the coils to change the aim of the beam to start a new horizontal scan or move from the bottom corner to the top)
If the concern is preventing anyone else from using your memory space because they arent supposed to be there for any reason, then that has been answered by others. Handled through the mmu, which unless you are running bare metal, the operating system has provided you with ram that you own, nobody else can get to it (other than the operating system). The mmu is setup so that you have a virtual address space that points at physical memory, but also it has controls as to who can access that memory and who cannot, thread id/virtual id, whatever, just like if you were to access memory outside your space, you would get a protection fault.
