What is the difference about Mutual Exclusion, between Monitor and Semaphore - mutex

I'm confused about Operating System's Synchronization part. I do not understand Mutual Exclusion issue with using at Monitor and Semaphore. Is that difference from each other?
Clearly; Does have Mutual Exclusion any difference with using at Monitor and Semaphore? Or do the same rules apply with using Mutual Exclusion at Monitor and Semaphore?
Additional Note = This sentence is confused me. "Semaphores and Monitors are all designed for solving mutual exclusion problem on one or more CPUs that all have access to a common memory"
Also I read those articles =
Monitor - Mutual Exclusion
Mutex vs Semaphore


Mutual exclusion is a requirement on the behaviour of multiple parallel processes that use shared memory. The sentence that confused you refers to this: common memory = shared memory.
The mutual exclusion requirement states that at most one process can be in its critical section at any given time (a critical section is a piece of program code that uses a specific resource residing in shared memory). The requirement does not say anything about how it can be achieved, only what has to be achieved.
Semaphores and monitors are devices with which mutual exclusion can be enforced, so they answer the "how" question. Both have to be used according to their own rules, but both can enforce mutual exclusion.
Hope this helps.


Here is how you should be thinking of mutual exclusion.
Mutual exclusion is to arbitrate the access of critical section(shared code among different threads) such that only one thread is allowed to execute the critical section at any time.There are multiple ways through which you can ensure mutual exclusion that includes the use of semaphore, mutex and monitors.It does not make any difference which mechanism you use for ensuring mutual exclusion whether semaphore or montior,The only difference is between the semaphore and monitor.semaphore are are genrally provide by os(although you can create your own) and monitors are programming language construct for providing mutual exclusion.

Related

What is meant by Distributed System?

I am reading about distributed systems and getting confused with what is really means?
I understand on high level, it means that set of different machines that work together to achieve a single goal.
But this definition seems too broad and loose. I would like to give some points to explain the reasons for my confusion:
I see lot of people referring the micro-services as distributed system where the functionalities like Order, Payment etc are distributed in different services, where as some other refer to multiple instances of Order service which possibly trying to serve customers and possibly use some consensus algorithm to come to consensus on shared state (eg. current Inventory level).
When talking about distributed database, I see lot of people talk about different nodes which possibly use to store/serve a part of user request like records with primary key from 'A-C' in first node 'D-F' in second node etc. On high level it looks like sharding.
When talking about distributed rate limiting. Some refer to multiple application nodes (so called distributed application nodes) using a single rate limiter, some other mention that the rate limiter itself has multiple nodes with a shared cache (like redis).
It feels that people use distributed systems to mention about microservices architecture, horizontal scaling, partitioning (sharding) and anything in between.

I am reading about distributed systems and getting confused with what is really means?
As commented by #ReinhardMänner, the good general term definition of distributed system (DS) is at https://en.wikipedia.org/wiki/Distributed_computing
A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system. The components interact with one another in order to achieve a common goal.
Anything that fits above definition can be referred as DS. All mentioned examples such as micro-services, distributed databases, etc. are specific applications of the concept or implementation details.
The statement "X being a distributed system" does not inherently imply any of such details and for each DS must be explicitly specified, eg. distributed database does not necessarily meaning usage of sharding.

I'll also draw from Wikipedia, but I think that the second part of the quote is more important:
A distributed system is a system whose components are located on
different networked computers, which communicate and coordinate their
actions by passing messages to one another from any system. The
components interact with one another in order to achieve a common
goal. Three significant challenges of distributed systems are:
maintaining concurrency of components, overcoming the lack of a global clock, and managing the independent failure of components. When
a component of one system fails, the entire system does not fail.
A system that constantly has to overcome these problems, even if all services are on the same node, or if they communicate via pipes/streams/files, is effectively a distributed system.
Now, trying to clear up your confusion:
Horizontal scaling was there with monoliths before microservices. Horizontal scaling is basically achieved by division of compute resources.
Division of compute requires dealing with synchronization, node failure, multiple clocks. But that is still cheaper than scaling vertically. That's where you might turn to consensus by implementing consensus in the application, or using a dedicated service e.g. Zookeeper, or abusing a DB table for that purpose.
Monoliths present 2 problems that microservices solve: address-space dependency (i.e. someone's component may crash the whole process and thus your component) and long startup times.
While microservices solve these problems, these problems aren't what makes them into a "distributed system". It doesn't matter if the different processes/nodes run the same software (monolith) or not (microservices), it matters that they are different processes that can't easily communicate directly (e.g. via function calls that promise not to fail).
In databases, scaling horizontally is also cheaper than scaling vertically, The two components of horizontal DB scaling are division of compute - effectively, a distributed system - and division of storage - sharding - as you mentioned, e.g. A-C, D-F etc..
Sharding of storage does not define distributed systems - a single compute node can handle multiple storage nodes. It's just that it's much more useful for a database that divides compute to also shard its storage, so you often see them together.
Distributed rate limiting falls under "maintaining concurrency of components". If every node does its own rate limiting, and they don't communicate, then the system-wide rate cannot be enforced. If they wait for each other to coordinate enforcement, they aren't concurrent.
Usually the solution is "approximate" rate limiting where components synchronize "occasionally".
If your components can't easily (= no latency) agree on a global rate limit, that's usually because they can't easily agree on a global anything. In that case, you're effectively dealing with a distributed system, even if all components just threads in the same process.
(that could happen e.g. if you plan to scale out but haven't done so yet, so you don't allow your threads to communicate directly.)

atomic operation definition and multiprocessor

I'm learning about synchronization and now I'm confused about the definition of atomic operation. Through searching, I could only find out that atomic operation is uninterruptible operation.
Then, won't the atomic operation only be valid for uni processor system since for multiprocessor system, many operation can be run simultaneously?

This link explains it pretty much perfectly (emphasis mine):
On multiprocessor systems, ensuring atomicity exists is a little
harder. It is still possible to use a lock (e.g. a spinlock) the same
as on single processor systems, but merely using a single instruction
or disabling interrupts will not guarantee atomic access. You must
also ensure that no other processor or core in the system attempts to
access the data you are working with. The easiest way to achieve this
is to ensure that the instructions you are using assert the 'LOCK'
signal on the bus, which prevents any other processor in the system
from accessing the memory at the same time. On x86 processors, some
instructions automatically lock the bus (e.g. 'XCHG') while others
require you to specify a 'LOCK' prefix to the instruction to achieve
this (e.g. 'CMPXCHG', which you should write as 'LOCK CMPXCHG op1,
op2').

Can single-processor systems handle multi-level queue scheduling?

I know that in Asymmetric multiprocessing one processor can make all the scheduling decisions whilst the others execute user code only. But is it possible for a single-processor system to allow for multi-level queue scheduling? And why?

Certainly a single processor system can use multi-level queue scheduling (MLQS). The MLQS algorithm is used to decide which process to run next when a processor becomes available. The algorithm doesn't require that there be more than one processor in the system. As a matter of fact, the algorithm is most efficient if there is only one processor. In a multi-processor system the data structure would need some sort of locking to prevent it from being corrupted.

how resource integrity is maintained using Semaphores

I am new to computer science and it may sound stupid to some of you. Although i have searched for related question, but this scenario stuck in my mind.
I understand that Mutexes provide lock facility for a section or resource. Consider the example of a buffer(an array of size 10 say) where a thread puts some value in it. We lock the mutex before using it releases after. This whole process is done by same thread.
Now if i have to do this same process with semaphores. I can limit the number of threads that can enter the critical section in this case. But how can the integrity of the buffer is maintained.
(read and write operations handled by different threads on buffer)

Semaphores are an higher abstraction. Semaphores controls the ability to create processes and make sure the instance created is distinct in which case it is kicked out. In a nutshell.

The usual solution with semaphores is to allow multiple simultaneous readers or one writer. See the Wikipedia article Readers-writers problem for examples.

Consistent hashing versus distributed locks for handling race conditions

In a distributed system where workload is distributed to multiple nodes, two of the ways of dealing with race conditions where multiple requests to operate on the same data concurrently are the use of consistent hashing and distributed locks. Consistent hashing would ensure that all requests to operate on one set of data are sent to the same worker and distributed locks would ensure that only one worker could operate on any set of data at a time.
My question is what are the pros and cons of either approach and which might be favorable?

The consistent hashing is much easier to implement than a distributed lock. The problem is specific distribution of inputs could be sent only to a subset of the nodes, resulting in some words working harder than others. Distributed lock is harder to implement and requires several communication messages (or some shared data) but won't result in a bias of node allocations.