What is the difference between Traffic Light and Monitor?

Question

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

• What would be the difference between them?

• Which is faster?

• And which is easier to use?
• Could you give me a basic example of each?

Answer 1

The monitor is a higher-level mechanism aimed at preventing inappropriate concurrent access, requiring an thread wait for another to finish what you’re doing. It is a specific object that controls this access to another main object that needs competition protection. It is a more ready mechanism, you just need to say you need to monitor this object, in some cases you need to say you no longer need.

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

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()
        }
    }
}

I put in the Github for future reference.

It can be implemented with several techniques, one of the most used is the traffic light, where there is information indicating whether the object can be accessed or not through an atomic counter (there is no risk of there being concurrent increment or decrement creating a running condition).

If there is indication that there is a thread working on the object in a situation that needs protection through this counter is like having a red light saying that 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 someone else to do what they want, which can cause a new state change to red. In general this is implemented as a state machine.

Obviously by being lower level the risk of doing something wrong is higher at traffic lights, it takes a little more work to control its functioning.

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

In general he can manage queues of threads who are waiting to operate on that object.

Pseudocode representing a traffic light:

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;
}

Source.

Mutex is another very common way to do the same. The biggest difference to a traffic light is that only the thread that blocked the object can release it. Another difference is that it only determines whether the object is locked or not.

Often we use the terms synchronization or locking to say more or less the same thing.

There are implementations that go beyond the process.

If someone says it’s not quite like that, there’s a chance she’s right, there’s a lot of controversial sources about what each one looks like. The subject is a little more complicated than this, maybe someone is in the patience to give more details.

Java works with monitors on all objects.