International Journal of Scientific & Engineering Research, Volume 3, Issue 10, October-2012 1
ISSN 2229-5518
Achieving a Real Multitasking, Multiprocessing and Multithreading by using Monitors.
Mr. M. S. Sonawane
Any object or thing in computer has its own “Monitor” So at a time only one task (program, process, or thread) can enter into monitor. So point to discuss is, at the depth or by looking from monitors view Where is the Multitasking (Multiprogramming, Multiprocessing, Multithreading)????? Even though there are DUAL Core Processors. So this paper discusses how we can achieve a real Multitasking, Multiprocessing & Multithreading by creating and maintaining number of monitors.
Parallel Computing, MultiCore Processor etc.
Multitasking, Multiprocessing and Multithreading, Monitors, Object, Semaphore, Mutex.
Today, a large number of software solutions are multi-threaded. Many of our desktop applications, such as word processors and web browsers, require multiple tasks executing concurrently to implement a seamless solution. Company services, such as purchasing or scheduling, use web-based, multi-tier solutions that must scale to allow millions of simultaneous users to perform transactions that access shared data. Though multi-threading enable the creation of complex systems, it introduces complexities in their development. When multiple threads are executed within a system, the execution order and time allotted for each is non-deterministic. As a result, they may display different behaviors from execution to execution. This non- determinism must be managed by means of thread synchronization to ensure that threads behave as expected.
One of the strengths of the programming language Java is its support for multithreading. This support centers on synchronization i.e.:- coordinating activities & data access among multiple threads. The mechanism used to support synchronization can be Monitor, Semaphore, Mutex and so on.
A monitor is like a building that contains one special room that can be occupied by only one thread at a time. The room usually contains some data. From the time a thread enters this room to the time it leaves, it has exclusive access to any data in the room. Entering the monitor building is called "entering the monitor." Entering the special room inside the building is called "acquiring the
monitor." Occupying the room is called "owning the monitor," and leaving the room is called "releasing the monitor." Leaving the entire building is called "exiting the monitor." In addition to being associated with a bit of data, a monitor is associated with one or more bits of code, which in this paper will be called monitor regions. A monitor region is code that needs to be executed as one indivisible operation with respect to a particular monitor.
Concurrency has always been an OS issue
o Resource allocation is necessary among competing processes
o Timer interrupts
Existing synchronization mechanisms (semaphores, locks) are subject to hard-to-find, subtle bugs.
One thread must be able to execute a monitor region from beginning to end without another thread concurrently executing a monitor region of the same monitor. A monitor enforces this one-thread-at-a-time execution of its monitor regions. The only way a thread can enter a monitor is by arriving at the beginning of one of the monitor regions associated with that monitor. The only way a thread can move forward and execute the monitor region is by acquiring the monitor. When a thread arrives at the beginning of a monitor region, it is placed into an entry set for the associated monitor. The entry set is like the front hallway of the monitor building. If no other thread is waiting in the entry set and no other thread currently owns the monitor, the thread acquires the monitor and continues executing the monitor region. When the thread finishes executing the monitor region, it exits (and releases) the monitor.
The synchronization supported by monitors is cooperation are mutual exclusion and Cooperation. Mutual exclusion helps keep threads from interfering with one another while sharing data, cooperation helps threads to work together towards some common goal.
Cooperation is important when one thread needs some data to be in a particular state and another thread is
IJSER © 2012 http://www.ijser.org
International Journal of Scientific & Engineering Research, Volume 3, Issue 10, October-2012 2
ISSN 2229-5518
responsible for getting the data into that state. For example,
one thread, a "read thread," may be reading data from a buffer that another thread, a "write thread," is filling. The read thread needs the buffer to be in a "not empty" state before it can read any data out of the buffer. If the read thread discovers that the buffer is empty, it must wait. The write thread is responsible for filling the buffer with data. Once the write thread has done some more writing, the read thread can do some more reading. The form of monitor used by the Java virtual machine is called a "Wait and Notify" monitor. (It is also sometimes called a "Signal and Continue" monitor.) In this kind of monitor, a thread that currently owns the monitor can suspend itself inside the monitor by executing a wait command. When a thread executes a wait, it releases the monitor and enters a wait set. The thread will stay suspended in the wait set until some time after another thread executes a notify command inside the monitor. When a thread executes a notify, it continues to own the monitor until it releases the monitor of its own accord, either by executing a wait or by completing the monitor region. After the notifying thread has released the monitor, the waiting thread will be resurrected and will reacquire the monitor.
A graphical depiction of the kind of monitor used by a Java virtual machine is shown in Figure. This figure shows the monitor as three rectangles. In the center, a large rectangle contains a single thread, the monitor's owner. On the left, a small rectangle contains the entry set. On the right, another small rectangle contains the wait set. Active threads are shown as dark gray circles. Suspended threads are shown as light gray circles.
A Java monitor is a specialized class that is used to encapsulate application specific thread synchronization logic in a Java program. This class consists of one or more synchronized methods, each of which is a critical section of the monitor and guarded by a single lock object. This lock object is implicitly acquired and released each time a thread enters and exits a critical section. A model of a Java monitor can be seen in Figure.
Once a thread is executing in a synchronized method of the monitor, all other
threads attempting to execute a synchronized method must wait in the monitor’s entry. A thread that has entered a critical section, may exit the critical section either by successful completion of its method or by making a call to one of the wait primitives. If a wait primitive is called, the thread must release its lock after which it is moved to the monitor’s wait queue. After a thread releases its lock and exits the critical section, a thread is selected from the entry queue, allowing it to acquire the lock and enter the critical section. For a threads to exit the wait queue, another thread executing in a critical section must make a notify or notifyAll primitive call. If the wait queue is not empty at the time these calls are made, one or more threads are moved from the wait queue to the entry queue before execution resumes in the calling thread. This type of signaling discipline is known as signal-and-continue. The only difference between these primitives is that the notify call will result in the selection of a random thread from the wait queue, while a notifyAll call affects all threads in the wait queue. It is also possible for a thread to exit the wait queue if it called a wait primitive with a timeout argument. In this event, if the thread is still waiting after the timeout period has expired, it will be moved to the entry queue. We will not address this type of wait primitive in our approach.
IJSER © 2012 http://www.ijser.org
International Journal of Scientific & Engineering Research, Volume 3, Issue 10, October-2012 3
ISSN 2229-5518
occupied = true;
procedure exitCar() //procedure occupied = false;
nonOccupied.signal;
Monitors are a programming language construct
Anonymous lock issues handled by compiler and
OS
Detection of invalid accesses to critical sections happens at compile time
Process of detection can be automated by compiler by scanning the text of the program
name: monitor
…local declarations
…initialize local data proc1 (…parameters)
…statement list
proc2 (…parameters)
…statement list proc3 (…parameters)
…statement list
Mutual exclusion
Encapsulation of data
Compiler can automatically scan program text for some types of synchronization
bugs
Synchronization of shared data access simplified vs. semaphores and locks
Good for problems that require course granularity
Invariants are guaranteed after waits
o Theoretically, a process that waits on a condition doesn’t have to retest the condition when it is awakened.
Data access synchronization simplified (vs. semaphores or locks)
Better encapsulation
So my proposed work suggests we can achieve real multitasking, multiprocessing, multithreading by creating number of monitors for object which will execute multiple threads at a time.
car: monitor //monitor declaration occupied: Boolean; occupied := false; //local variables /
initializations nonOccupied: condition;
procedure enterCar() //procedure if occupied then nonOccupied.wait;
IJSER © 2012 http://www.ijser.org
International Journal of Scientific & Engineering Research, Volume 3, Issue 10, October-2012 4
ISSN 2229-5518
A "ready" or "waiting" process has been loaded into main memory and is awaiting execution on a CPU (to be context switched onto the CPU by the dispatcher, or short-term scheduler). There may be many "ready" processes at any one point of the systems execution ,all other "concurrently executing" processes will be waiting for execution. A ready queue is used in computer scheduling. Modern computers are capable of running many different programs or processes at the same time. Processes that are ready for the CPU are kept in a queue for "ready" processes. Other processes that are waiting for an event to occur, such as loading information from a hard drive or waiting on an internet connection are not in the ready queue, they are putted in waiting queue.
Fig: Workflow Diagram
Mapping Unit will map each and every process to corresponding monitor and will make the entry in Monitor Table. All the monitor objects will communicate with each other for updated data by using Message Passing.
Even though monitor is a higher level, easier to use
abstraction, better encapsulation as compare to semaphores/locks. It has several drawbacks like in conventional multitasking, multiprocessing, multithreading at a time only one process is able to use the object’s monitor. So problem arises when more than one processes needs to access same monitor at the same time. Because of this we are not getting actual multitasking.
Using this framework process will get required monitor whenever needed because we have created multiple monitors of an object. So the proposed work suggests we can achieve real multitasking, multiprocessing, multithreading by creating number of monitors for object which will used by multiple threads or processes at the same time.By creating a number of monitors real multitasking, multiprocessing, multithreading achieved with faster speed.
“Monitors: An Operating System Structuring Concept,”
Hoare.
Modern Operating Systems, Second Edition, Tannenbaum, pp. 115-119.
IJSER © 2012 http://www.ijser.org
International Journal of Scientific & Engineering Research, Volume 3, Issue 10, October-2012 5
ISSN 2229-5518
Jon Walpole, correspondence.
Emerson Murphy-Hill presentation from CS533, Winter 2005
http://en.wikipedia.org/wiki/C._A._R._Hoare
Mr. M. S. Sonawane
Asst. Professor
Institute of Management Research and Development, Near
Karwand Naka, Shirpur Dist-Dhule (MH) manojkumar.sonawane@rediffmail.com
IJSER © 2012 http://www.ijser.org