What is the difference... - Linux

This is a discussion on What is the difference... - Linux ; How the Mutex, Semaphores and Monitors Differs from each other?...

+ Reply to Thread
Results 1 to 4 of 4

Thread: What is the difference...

  1. What is the difference...

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

  2. Re: What is the difference...

    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. ------



  3. Re: What is the difference...

    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)?

  4. Re: What is the difference...

    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!!!

+ Reply to Thread