What is the difference between Semaphore and Monitor?

7

I have a doubt in the concept of these two structures .

  • What would be the difference between them?

  • Which is faster?

  • Which is easier to use?
  • Could you give me a basic example of each?
asked by anonymous 31.05.2017 / 00:33

1 answer

7

The monitor is a higher-level mechanism whose purpose is to prevent inappropriate concurrent access by forcing thread wait for another to finish what they are doing. It is a specific object that controls this access to another main object that needs concurrency protection. It's a faster mechanism, you just need to say that you need to monitor this object, in some cases you need to say you do not need it any more.

A code taken from Wikipedia demonstrates how it works (note that it is possible for the language to hide the complexity of it all):

class Account {
    private lock myLock //isto pode ser escondido do código
    private int balance := 0
    invariant balance >= 0

    public method boolean withdraw(int amount)
        precondition amount >= 0 {
        myLock.acquire() //isto pode ser simplificado no código
        try {
            if balance < amount {
                return false
            } else {
                balance := balance - amount
                return true
            }
        } finally {
            myLock.release()
        }
    }

    public method deposit(int amount)
        precondition amount >= 0 {
        myLock.acquire() //isto pode ser simplificado no código
        try {
            balance := balance + amount
        } finally {
            myLock.release()
        }
    }
}

It can be implemented with several techniques, one of the most used is the semaphore , where there is a information that indicates whether or not the object can be accessed through an atomic counter (there is no risk of concurrent increment or decrement by creating a race condition ).

If there is an indication that a thread working on the object in a situation that needs protection through this counter is as if it had a red sign saying no one can do what they want. When this operation ends, the state of the traffic light is changed, that is, it gives the green light to another to do what you want, which may cause a new state change to red. In general this is implemented as a state machine .

Obviously because the level is lower, the risk of doing something wrong is greater at the traffic light, it gives a bit more work to control its operation.

The monitor tends to be faster and so is preferred today, whenever possible.

In general, it can handle threads queues that are waiting to operate on that object.

Pseudocode representing a semaphore:

struct Semaphore { //pode ser o mesmo do lock usado no monitor
    int value; //o mutex costuma ser só um booleano
    Queue q;
} S;
withdraw(account, amount) {
wait(S);
    balance = get_balance(account);
    balance -= amount;
    put_balance(account, balance);
    signal(S);
    return balance;
}
wait(S) {
    Disable interrupts;
    while (S->value == 0) {
        enqueue(S->q, current_thread);
        thread_sleep(current_thread);
    }
    S->value--;
    Enable interrupts;
}
signal(S) {
    Disable interrupts;
    thread = dequeue(S->q);
    thread_start(thread);
    S->value++;
    Enable interrupts;
}

Font .

Mutex is another very common way of doing the same. The biggest difference for a semaphore is that only the thread that locked the object can release it. Another difference is that it only determines whether the object is locked or not.

Many times the terms synchronization or locking are used to say more or less the same thing.

There are implementations that go beyond the process.

If someone says it's not quite right, you have a chance of being right, you have controversial sources about what each is like. The subject is a bit more complicated than this, maybe someone is patient to give more details.

Java works with monitors on all objects .

    
31.05.2017 / 02:31