1 20 pts For the following program explain the interesting e

1. (20 pts) For the following program, explain the interesting elements related to threads.

You may experiment with the program using the attached source code: TaskThreadDemo source code

1  public class TaskThreadDemo {
2    public static void main (String args []) {
3    String [] sa = {\"a\", \"X\", \"+\", \".\"};
4    for (String s: sa) {
5      Runnable ps = new PrintChar (s, 200);
6      Thread ts = new Thread (ps, s);
7      ts.start ();
8    } // end for each character
9    } // end main
10 } // end class TaskThreadDemo
11
12 class PrintChar implements Runnable {
13   String ch;
14   int times;
15
16   public PrintChar (String c, int n) {
17     ch = c;
18     times = n;
19   } // end constructor
20
21   public void run () {
22     for (int i = 0; i < times; i++) {
23       System.out.print (ch);
24     } // end for loop
25   } // end method run
26 } // end class PrintChar

2. (20 pts) What is changed if the method called on line 7, start(), is replaced with run()? Explain (of course).

3. (20 pts) What is changed if the method Thread.yield() is added between lines 23 and 24? Explain.

4. (20 pts) List and explain the threads running in your SeaPort program as reported by jconsole. Note that you can name the threads created in the program, as is done on line 6 in Problem 1 above, which can make this discussion a lot easier to follow.

5. (20 pts) Explain how the java.util.concurrent.Semaphore might class be used in the SeaPort program, final project, to coordinate the requirements of the various jobs. Then address the question of whether or not this actually makes sense in the context of the requirements of program. In other words, can you suggest approaches to handling shared resource pools that would be simpler than using semaphores?

Solution

1.start() method of Thread class is used to start a newly created thread. It performs following tasks:

Runnable interface:

public void run(): is used to perform action for a thread.

2.the output was changed when we replace start(0 with run() in line 7,

before changing ........................................................................................................................................................................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

after changing output become

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++........................................................................................................................................................................................................

3.Thread.yield() method causes the currently executing thread object to temporarily pause and allow other threads to execute.
Means when we add this,the current thread is pause for some time and next thread starts,ultimately concurrency between two threads occurs.output becomes

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.

4.

JConsole can monitor itself. This ability is useful for simple troubleshooting of the Java environment.

5.

Semaphores might be appropriate for signaling between processes. For multithreaded programming, semaphores should be avoided. If you need exclusive access to a resource, use mutex. If you need to wait for a signal, use condition variable.

Even the most often mentioned case of a resource pool can be implemented simpler and safer with a condition variable than with a semaphore. Let\'s look at this case. A naive implementation with a semaphore would look like (pseudocode):

The first problem is that semaphore does not protect the pool from being accessed by several threads. So, another protection is required. Let it be a lock:

Additional measures need to be taken to ensure the pool is not empty when accessed. Technically it is possible to access the pool bypassing the semaphore, but it would break resource availability guarantees for the acquisition procedure above. So the pool should be only accessed via that procedure.

So far so good, but what if a thread does not want to wait passively for a resource? Can non-blocking resource acquisition be supported? It\'s easy if the semaphore itself supports non-blocking acquisition; otherwise (e.g. on Windows) this will be problematic. The semaphore cannot be bypassed, because it would break the blocking case. Passing through the semaphore only if the pool is not empty may lead to a deadlock if done under the lock, but as soon as the lock is released, the result of the check for emptiness becomes useless. It is probably doable (I did not try), but surely leads to significant additional complexity.

With condition variable, this is solved easily. Here is the pseudocode with blocking acquisition:

And in this case there is no problem to add non-blocking acquisition:

As you may see, it does not even need to access condition variable, and makes no harm to the blocking case. To me, it\'s clearly superior to the use of semaphore.