Question

TRUE-FALSE     Basic synchronization principles and multithreading

1. Java user threads can implement both busy-waiting and no-busy-waiting policy.

2. Priority inversion avoids deadlocks.

3. Spinlock mutex can be used as an adaptive mutex.

4. Java RTE can be blocked for Input/Output operation.

5. Interrupted user thread, which executes a method in a monitor, must be rolled back to undo any changes it performed.

6. The synchronization primitive by disabling interrupts can be used by an application program.

7. Bounded-waiting requirement is met when a process k desires to enter the critical section; it could be able to enter the critical section after some limited wait.

8. Busy waiting means that a thread is waiting for a condition to be satisfied in a tight loop without relinquishing the processor.

9. Mutual exclusion may be violated if the wait() and signal() operations are not executed atomically.

10. Throughput in the readers-writers problem is decreased by favoring multiple readers as opposed to allowing a single writer to exclusively access the shared values.

11. The signal() operation associated with monitors differ from the corresponding signal() operation defined for semaphores.

12. Solaris, Linux, and Windows use adaptive mutex as a synchronization mechanism only on multiprocessor systems

13. All user threads in Java applications are subclasses that extend class Thread.

14. The thread invokes the method run() to start the executable code.

15. The method isAlive() returns FALSE if the thread is blocked after wait() method.

16. Java multithreading follows preemptive mode with priorities.

17. Deamon threads cannot be preemptive.

18. In Java notify() and notifyAll() are methods of Thread class.

19. The monitor synchronization does not assign a lock to the shared data, but locks the method that manipulates the shared data.

20. All Java methods must either catch or throw InteruptedException.

Answer 1

6th one is true because

shared double balance;

Code for p1       Code for p2

disableInterrupts(); disableInterrupts();

balance = balance + amount; balance = balance - amount;

enableInterrupts(); enableInterrupts();

Disabling interrupts guarantees mutual exclusion, but

lA user process can easily abuse this privilege and hence should not be available to a user process.

l

lInterrupts could be disabled arbitrarily long

l

lWe only want to prevent p1 and p2 from interfering with one another; this prevents any other process pk to execute

lIn a Multiprocessor system, disabling interrupts in one processor will not disable it in another process and hence mutual exclusion is not guaranteed

20 is false because

InterruptedException is (usually) thrown when thread blocked on a method gets interrupt()called on it.

The point of it is to unblock (for some reason) a thread that is blocked. Example of reason is application shutdown. So, when you shutdown your application, if you have threads waiting on let say sleep() or wait() , if you do not tell them that you are shutting down they will continue to wait(). If those threads are not daemon threads, then your application won't shutdown.

So, when thread gets interrupted during sleep(), you have to check the conditions and handle the situation. In case of shutdown, you have to check your shutdown flag and eventually do the clean-up work and let the thread go.

Threads can be interrupted because of some other reasons, but the point is the same. If you have multi-threaded application you have to establish protocol for your threads so that they know when there is some special condition how to handle it. In case the thread is waiting/sleeping, you have to wake it up to handle the situation. The clinets of your library or framework do not know anytrhing about your protocol, so they don't know how to handle InterruptedException because of that the recomendation is to handle it in your library/framework code.

12th one true because

These operating systems provide different locking mechanisms depending on the application developers’ needs. Spinlocks are useful for multiprocessor systems where a thread can run in a busy-loop (for a short period of time) rather than incurring the overhead of being put in

a sleep queue. Mutexes are useful for locking resources. Solaris 2 uses adaptive mutexes, meaning that the mutex is implemented with a spin lock on multiprocessor machines. Semaphores and condition variables are more appropriate tools for synchronization when a resource must be held for a long period of time, since spinning is inefficient for a long duration

17th is true because daemon threads run in low priority but premptive means it runs in high priority

18th false because in java Notify() and notifyAll() is declared in object class instead of thread