On August 7, 2008 08:48, in comp.os.linux.development.system, Pranav
(pranav026@gmail.com) wrote:

> How the Mutex, Semaphores and Monitors Differs from each other?

A "mutex" (or "mutual exclusion lock") is a signal that two or more
asynchronous processes can use to reserve a shared resource for exclusive
use. The first process that obtains ownership of the "mutex" also obtains
ownership of the shared resource. Other processes must wait for for the
first process to release it's ownership of the "mutex" before they may
attempt to obtain it.

A concrete example of a "mutex" would be a bathroom door. Each person
wishing to use the toilet must first be able to open the bathroom door. If
they cannot open the door (because it is locked), they wait outside the
bathroom until the current occupant finishes with the toilet, and unlocks
the door. Each successive occupant locks the door before using the toilet
(thus preventing others from entering and attempting to use the toilet
while they are using it), and unlocks the door after they are done. The
bathroom door is a "mutex" mechanism for the toilet (shared resource)
inside.

A "monitor" is a type of program block that hides all the complexity of
managing a semaphore by turning the processing "inside-out". Instead of
each independant thread /asking/ for its own access to a semaphore, the
monitor runs and /gives/ one thread access at a time. The kernel to an
operating system usually acts as a "monitor" to the user processes, giving
them access to the CPU, and taking it away as the monitor program sees fit.

To extend our "mutex" example a bit, a concrete example of a "monitor" might
be a bathroom attendant, who permits patrons to enter the bathroom, one at
a time, and asks them to leave when their time is up. In order to ensure
that the bathroom patron interacts with the "monitor", there's no toilet
paper in the bathroom; the patron has to ask the "monitor" for the paper
when they are ready for it. The "monitor" would then use this conversation
as an opportunity to ask the bathroom patron to leave, if there are more
patrons waiting.

Finally, a "semaphore" is a sort of "mutex" that is used to signal the
availability of a plentiful resource. The source of the resource adds one to
the semaphore for each unused resource available. As resources are taken
away, the count in the semaphore is decremented (one for each removed
resource) until it reaches zero (meaning that no more resources are
available). At this point, any remaining consumers of the resource must
wait until the "semaphore" increments above zero, indicating that more
resources are available.

A concrete example of a "semaphore" would be the "Number of cups" level on
your coffee urn. Your coffee urn starts off full, with a large "number of
cups". As each coffee drinker pours a cup, the level in the urn goes down
and the "number of cups" count decreases. When the last of the coffee is
poured, the "number of cups" reaches zero and someone refills the urn. Any
further coffee drinkers must wait until the "number of cups" in the coffee
urn has increased above zero. As it does, each drinker in turn can pour a
cup (thus decreasing the count again), until the count again reaches zero.

Does this help?

PS: Read the first two chapters of "Operating Systems - Design and
Implementation" by Andy Tanenbaum. It's all there (except for the colourful
examples :-) ).

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

On Aug 7, 8:53 pm, Lew Pitcher wrote:
> On August 7, 2008 08:48, in comp.os.linux.development.system, Pranav
>
> (pranav...@gmail.com) wrote:
> > How the Mutex, Semaphores and Monitors Differs from each other?
>
> A "mutex" (or "mutual exclusion lock") is a signal that two or more
> asynchronous processes can use to reserve a shared resource for exclusive
> use. The first process that obtains ownership of the "mutex" also obtains
> ownership of the shared resource. Other processes must wait for for the
> first process to release it's ownership of the "mutex" before they may
> attempt to obtain it.
>
> A concrete example of a "mutex" would be a bathroom door. Each person
> wishing to use the toilet must first be able to open the bathroom door. If
> they cannot open the door (because it is locked), they wait outside the
> bathroom until the current occupant finishes with the toilet, and unlocks
> the door. Each successive occupant locks the door before using the toilet
> (thus preventing others from entering and attempting to use the toilet
> while they are using it), and unlocks the door after they are done. The
> bathroom door is a "mutex" mechanism for the toilet (shared resource)
> inside.
>
> A "monitor" is a type of program block that hides all the complexity of
> managing a semaphore by turning the processing "inside-out". Instead of
> each independant thread /asking/ for its own access to a semaphore, the
> monitor runs and /gives/ one thread access at a time. The kernel to an
> operating system usually acts as a "monitor" to the user processes, giving
> them access to the CPU, and taking it away as the monitor program sees fit.
>
> To extend our "mutex" example a bit, a concrete example of a "monitor" might
> be a bathroom attendant, who permits patrons to enter the bathroom, one at
> a time, and asks them to leave when their time is up. In order to ensure
> that the bathroom patron interacts with the "monitor", there's no toilet
> paper in the bathroom; the patron has to ask the "monitor" for the paper
> when they are ready for it. The "monitor" would then use this conversation
> as an opportunity to ask the bathroom patron to leave, if there are more
> patrons waiting.
>
> Finally, a "semaphore" is a sort of "mutex" that is used to signal the
> availability of a plentiful resource. The source of the resource adds one to
> the semaphore for each unused resource available. As resources are taken
> away, the count in the semaphore is decremented (one for each removed
> resource) until it reaches zero (meaning that no more resources are
> available). At this point, any remaining consumers of the resource must
> wait until the "semaphore" increments above zero, indicating that more
> resources are available.
>
> A concrete example of a "semaphore" would be the "Number of cups" level on
> your coffee urn. Your coffee urn starts off full, with a large "number of
> cups". As each coffee drinker pours a cup, the level in the urn goes down
> and the "number of cups" count decreases. When the last of the coffee is
> poured, the "number of cups" reaches zero and someone refills the urn. Any
> further coffee drinkers must wait until the "number of cups" in the coffee
> urn has increased above zero. As it does, each drinker in turn can pour a
> cup (thus decreasing the count again), until the count again reaches zero.
>
> Does this help?
>
> PS: Read the first two chapters of "Operating Systems - Design and
> Implementation" by Andy Tanenbaum. It's all there (except for the colourful
> examples :-) ).
>
> --
> Lew Pitcher
>
> Master Codewright & JOAT-in-training | Registered Linux User #112576http://pitcher.digitalfreehold.ca/ | GPG public key available by request
> ---------- Slackware - Because I know what I'm doing. ------

Thank You Lew Pitcher, For your in-depth explanation with very good
examples that can be kept in mind. One more thing can we create our
own monitors for defined semaphores/mutexes schedule entities using
monitors(without any aid from kernel directly)?

On Aug 8, 1:53*am, Lew Pitcher wrote:
> On August 7, 2008 08:48, in comp.os.linux.development.system, Pranav
>
> (pranav...@gmail.com) wrote:
> > How the Mutex, Semaphores and Monitors Differs from each other?
>
> A "mutex" (or "mutual exclusion lock") is a signal that two or more
> asynchronous processes can use to reserve a shared resource for exclusive
> use. The first process that obtains ownership of the "mutex" also obtains
> ownership of the shared resource. Other processes must wait for for the
> first process to release it's ownership of the "mutex" before they may
> attempt to obtain it.
>
> A concrete example of a "mutex" would be a bathroom door. Each person
> wishing to use the toilet must first be able to open the bathroom door. If
> they cannot open the door (because it is locked), they wait outside the
> bathroom until the current occupant finishes with the toilet, and unlocks
> the door. Each successive occupant locks the door before using the toilet
> (thus preventing others from entering and attempting to use the toilet
> while they are using it), and unlocks the door after they are done. The
> bathroom door is a "mutex" mechanism for the toilet (shared resource)
> inside.
>
> A "monitor" is a type of program block that hides all the complexity of
> managing a semaphore by turning the processing "inside-out". Instead of
> each independant thread /asking/ for its own access to a semaphore, the
> monitor runs and /gives/ one thread access at a time. The kernel to an
> operating system usually acts as a "monitor" to the user processes, giving
> them access to the CPU, and taking it away as the monitor program sees fit.
>
> To extend our "mutex" example a bit, a concrete example of a "monitor" might
> be a bathroom attendant, who permits patrons to enter the bathroom, one at
> a time, and asks them to leave when their time is up. In order to ensure
> that the bathroom patron interacts with the "monitor", there's no toilet
> paper in the bathroom; the patron has to ask the "monitor" for the paper
> when they are ready for it. The "monitor" would then use this conversation
> as an opportunity to ask the bathroom patron to leave, if there are more
> patrons waiting.
>
> Finally, a "semaphore" is a sort of "mutex" that is used to signal the
> availability of a plentiful resource. The source of the resource adds oneto
> the semaphore for each unused resource available. As resources are taken
> away, the count in the semaphore is decremented (one for each removed
> resource) until it reaches zero (meaning that no more resources are
> available). At this point, any remaining consumers of the resource must
> wait until the "semaphore" increments above zero, indicating that more
> resources are available.
>
> A concrete example of a "semaphore" would be the "Number of cups" level on
> your coffee urn. Your coffee urn starts off full, with a large "number of
> cups". As each coffee drinker pours a cup, the level in the urn goes down
> and the "number of cups" count decreases. When the last of the coffee is
> poured, the "number of cups" reaches zero and someone refills the urn. Any
> further coffee drinkers must wait until the "number of cups" in the coffee
> urn has increased above zero. As it does, each drinker in turn can pour a
> cup (thus decreasing the count again), until the count again reaches zero..
>
> Does this help?
>
> PS: Read the first two chapters of "Operating Systems - Design and
> Implementation" by Andy Tanenbaum. It's all there (except for the colourful
> examples :-) ).
>
> --
> Lew Pitcher
>
> Master Codewright & JOAT-in-training | Registered Linux User #112576http://pitcher.digitalfreehold.ca/* | GPG public key available by request
> ---------- * * *Slackware - Because I know what I'm doing. * * * * *------

Excellent examples and explanations Lew! I'm more of a Spinlock on
the bathroom door!!!