Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

Q: Read the manual (or any resources) about the implementation of PThread condit

ID: 3844748 • Letter: Q

Question

Q: Read the manual (or any resources) about the implementation of PThread condition variables and give answer to following questions: 1. Why the condition variable requires a mutex? 2. What happens if a thread is woken up (from wait) but cannot acquire the lock? 3. When signal happens for a condition, and if more than one thread are waiting for that condition: a. How many threads will be woken up? b. Could you ensure an order among the threads for waking up? If yes, how? c. How can you make all the threads to wake up?

Explanation / Answer

Mutexes: Routines that deal with synchronization, called a "mutex", which is an abbreviation for "mutual exclusion". Mutex functions provide for creating, destroying, locking and unlocking mutexes. These are supplemented by mutex attribute functions that set or modify attributes associated with mutexes.

The mutex used to protect the condition variable. It need locked before do a wait. The wait will atomically unlock the mutex, allowing others access to the condition variable (for signalling). Then when the condition variable is signalled or broadcast to, one or more of the threads on the waiting list will be woken up and the mutex will be magically locked again for that thread.

Thread is defined as an independent stream of instructions that can be scheduled to run as such by the operating system.

There are some possible reasons, if more than one condition to wait. Since we cannot control which thread gets the notification, it entirely possible that a notification wakes up a thread that is waiting for an entirely different condition. By waking up all the waiting threads, we can design the program so that the threads decide among themselves which should execute next. Another reason is the case where the notification can satisfy multiple waiting threads.

If there is at least one threads were blocked on the condition variable, one of them is unblocked. The awakened thread will be automatically granted the lock it originally owned when executed cond_wait().

When no threads are blocked on the condition variable, cond_signal() has no effect. Calling cond_signal() should also be protected with a lock that is used to protect the call to cond_wait().

Since threads are continually testing a variable to know if a condition is met, some thread who takes the responsibility to signal a condition variable must set the condition to indicate that the condition occurs. In the above, if condition is met, a thread calls cond_signal(). Thus, one thread waiting on that condition is awakened, retests the condition, and perhaps continues.

Lock an object that can only be owned by a single thread at any given time. Basic operations on a lock. Acquire mark the lock as owned by the current thread; if some other thread already owns the lock then first wait until the lock is free. Lock typically includes a queue to keep track of multiple waiting threads. Release mark the lock as free (it must currently be owned by the calling thread).

Threads are represented by the Thread class. The only way for a user to create a thread is to create an object of this class; each thread is associated with such an object. A thread will start when the start() method is invoked on the corresponding Thread object.

Every object, in addition to having an associated monitor, has an associated wait set. A wait set is a set of threads. When an object is first created, its wait set is empty. Elementary actions that add threads to and remove threads from wait sets are atomic. Wait sets are manipulated solely through the methods Object.wait, Object.notify, and Object.notifyAll.

Wait set manipulations can also be affected by the interruption status of a thread, and by the Thread class's methods dealing with interruption. Additionally, the Thread class's methods for sleeping and joining other threads have properties derived from those of wait and notification actions.

ALL THREADS IF condition.await()

public Object getObject() {

lock.lock();

try {

    int localstate = this.state;

    while (check && localstate == this.state)) {

      condition.await(); // all threads that are waiting here have the same state

    }

    if (!check) {

      this.state++; // first thread will change state thus making other threads ignore the 'check' value

    }

    return returnObjectAndSetCheckToFalse();

} finally {

    lock.unlock();

}

}