Conceptual: Assigning threads to different CPU cores , Mutexes vs Semaphores

[GroovyJack]

Hello, I am trying to figure out some things relating to a learning exercise in Operating Systems. We must explain, conceptually the following.

1. What is the disadvantage of always assigning a thread to a different CPU core each time it is allowed to execute?

2. What is the main differences between mutexes and semaphores, specifically a key difference between the mutex and a binary semaphore.

So far I understand that if there is only one core, then the operating system schedules the most eligible thread to run on that core for a time slice. After a time slice is completed, or when the running thread blocks on IO, or when the processor is interrupted by external events, the operating system reevaluates what thread to run next (and it could choose the same thread again or a different one).

Eligibility to run consists of variations on fairness and priority and readiness, and by this method various threads get time slices, some more than others. If there are multiple cores, N, then the operating system schedules the most eligible N threads to run on the cores.

Processor Affinity is an efficiency consideration. Each time a CPU runs a different thread than before, it tends to slow down a bit because its cache is warm for the previous thread, but cold to the new one. Thus, running the same thread on the same processor over numerous time slices is an efficiency advantage.

However, the operating system is free to offer one thread time-slices on different CPUs, and it could rotate through all the CPUs on different time slices. It cannot run one thread on multiple CPUs simultaneously. Am I missing anything?


Secondly with the mutexes and semaphores, I know that mutex values can be modified just as locked or unlocked. Multiple number of threads can acquire binary semaphore at a time concurrently. Binary semaphore have no ownership. There is ownership associated with mutex because only owner can release the lock. Could someone elaborate on the difference between these two please?

[jonnin]

I don't know how it works, but *IF* each cpu has its own cache, then 1) is a big problem. As in, you may as well not even have a cache. You nailed this, but maybe understated or underrealized how bad it would really be. I have an older game and a new cpu with 20 cores. I have to manually set that game to use only 4 cores via affinity or it actually slows way down (from seconds to min+ each area transition) for some weird reason, possibly something like this caused by an assumption about # of cores

[kigar64551]

1. What is the disadvantage of always assigning a thread to a different CPU core each time it is allowed to execute?

Yes, I think "moving" a thread between different CPU cores can have a negative effect on the CPU caches. Caches always need a "warm up" phase until they become effective. By moving the thread around, you have to go trough that "warm up" phase again, at least as far as L1/L2 caches are concerned. L3 is usually "shared".

But you really should let the OS decide which "core" a thread should run on. That is especially true with the latest processors that have separate "efficiency" and "performance" cores – plus a thread director. And even older processors with only one type of cores have so-called "preferred" cores that the OS tries to "fill" first.

2. What is the main differences between mutexes and semaphores, specifically a key difference between the mutex and a binary semaphore.

Two key differences, IMO:

1. A semaphore has a counter and it only "blocks" when a thread tries to acquire (decrement) the semaphore when its counter is already at zero (otherwise the counter is decremented without blocking), whereas a mutex only knows two states, locked or free, and it "blocks" when trying to acquire it in the locked state.

2. The thread that successfully locked (acquired) a mutex is considered to be "owning" that mutex. Usually, only the thread currently "owning" a mutex is allowed to unlock that mutex again! Conversely, the increment and decrement operations on a semaphore can be (and often are) performed by totally different threads.

💡 Because of (2), a mutex is not exactly the same as a semaphore with the counter limited to a max. of 1.


As an aside: In Win32 programming, there are "mutex" and "semaphore" objects that can be shared between different processes for inter-process synchronization. At the same time, a "critical section" (a light-weight and more efficient "mutex") is local to a process, i.e. it can not be shared across process boundary.