1

I've being trying to find an answer for that, and all I could find it that once a thread reaches a critical section it locks it in front of other threads (or some other lock mechanism is being used to lock the critical section).

But that implies that the threads didn't really reach the CS exactly at the same microsecond.

Although I guess it is quite rare, can it really happen, and what happens in this situation?

Can I simply assume the the program will malfunction?

Note: I am referencing to a multicore CPUs.

Thanks.

Jérôme Richard
  • 41,678
  • 6
  • 29
  • 59
dushkin
  • 1,939
  • 3
  • 37
  • 82

3 Answers3

1

I think you are missing the point of the fundamental locking primitives like Semaphores. If correct primitive is used, and used correctly, then the timing of the threads do not matter. They may well be simultaneous. The Operating System guarantees that no two thread will enter the critical section. Even on multicore machines, this bit is specially implemented (with lots of trickery even) to get that assurance.

To address your concerns specifically:

But that implies that the threads didn't really reach the CS exactly at the same microsecond.

No. The other threads could have reached in the same microsecond, BUT if the locking mechanism is correct, then only one the competing threads will "enter" the critical section and others will wait.

Although I guess it is quite rare, can it really happen, and what happens in this situation?

Rare or not, if the correct locking primitive is used, and used correctly, then no two threads will enter the critical section.

Can I simply assume the the program will malfunction?

Ideally the program should not malfunction. But any code will have bugs - so does your code and the Operating System code for the Semaphores. So it is safe to assume that in some edge cases the program will indeed malfunction. But this assumption is true for any code in general.

Locking and Critical Sections are rather tricky to correctly implement. So for non academic purposes we should always use the system provided locking primitives. All Operating Systems expose stuff like Semaphores which most programming languages have ways to use. Some programming languages have their own lightweight implementations which provide somewhat softer guarantees but at a higher performance. As I said, while doing Critical Sections, it is critical to choose the correct thing and also to implement it correctly.

inquisitive
  • 3,549
  • 2
  • 21
  • 47
  • When you say "correct locking primitive" you mean the one that the programmer should set, right? And then, how does this locking primitive choose which one to enter first into the CS? – dushkin Mar 21 '21 at 12:21
  • 1
    It requires some explicit support from the hardware in order to reliably work correctly on multi-CPU systems. Usually that support comes in the form of atomic operations, which the hardware guarantees will happen entirely or not at all (from the other CPUs' point of view). https://stackoverflow.com/questions/52196678/what-are-atomic-operations-for-newbies – Jeremy Friesner Mar 21 '21 at 13:14
  • locking primitive don't choose which one to enter first into the CS. almost always they use hardware features, microinstructions built into the processors to achieve that. there could be no uniform answer to the "how". you have to study different OS + CPU combinations. you can start with linux+x86. You can start here https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-3.html – inquisitive Mar 21 '21 at 13:24
1

...But that implies that the threads didn't really reach the CS exactly at the same microsecond.

Short answer; Memory system hardware makes it impossible for two different processors to access the same memory location at the same time. I'm not a computer architect, so I can't explain how it works, but the memory system serializes all of the accesses to the shared, main memory by the various CPUs in a multi-CPU system.

"Entering a critical section" means locking a mutex, and a mutex basically is just a flag in shared memory that is accesses by a specific protocol.

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57
1

It is the task of the cache coherence protocol to make sure there are no 2 writes on the same chunk of memory (cache line) at the same time. With MESI there can be multiple readers of the same cacheline, but only 1 writer.

So if 2 threads at the same time want to write to the same cacheline, their requests will be serialized by cache coherence protocol.

Most CPU architecture support atomic operations like CAS. On the X86 this can be done using a lock prefix. The CPU will lock the cacheline when it starts with the CAS instruction and will not respond to cache coherence requests from other cores till it is finished with the atomic operation.

So if you would have 2 CPUs that both want to do a CAS, these operations are serialized by the underlying hardware.

pveentjer
  • 10,545
  • 3
  • 23
  • 40