Alfonse, Your Java Is Ready!

Transcription

1 . Afonse, Your Java Is Ready! Stephen J. Hartey Math and Computer Science Department Drhxe University, Phiadephia, PA (215) Abstract i L L Is Java suitabe for teaching concurrent programming? This paper describes the features Java has for this, how we they work, and what is missing. The author has written a ibrary of casses, aso described here, to provide the missing features. Suppemented with these casses, Java works we as the concurrent programming anguage in operating systems and reated courses. ntrodktion The abundance of hype Java [AG96,.CH96, Sun971 receives shoud not distract us from the fact that it has many exceent features for teaching sequentia programming: object-oriented, no expicit pointers and no pointer arithmetic, automatic garbage coection and no memory eaks, strong typing, patform independence, and many compier and run-time checks. The deveopment kit (JDK) for the anguage comes with,a rich coection of cass ibraries (AI%) for data structures, IO, networking, remote procedure cas, and graphics. Since threads are buit-in, Java can be used for concurrent programming and deveoping mutithreaded appications. The question remains, however, whether Java is suitabe-as the concurrency patform in operating systems and reated courses to give students practice and experience [BC96] in concurrent programming. Besides supporting mutipe threads, a anguage for teaching concurrent programming shoud have semaphores and monitors for synchronizing threads sharing the same address space, and message passing capabiities so threads in different address spaces (perhaps on different computers) can communicate. Other desirabe features are the rendezvous and remote procedure cas for cientserver stye programming. These programming toos are described in many operating systems texts, such as [DeiSO, SG94, Sta95, TW97], and concurrent program- Permission to make digitahard copies of a or part of this materia for persona or cassroom use is granted without fe provided that the copies are not made or distributed for profit or cnmmercia advantage, the copyright notice, the tite ofthe pubication and its date appear, and notice is given that copyright is by pemuss~ on ofthe ACM, Inc. To copy otherwise, to repubish, to post on servers or to redistribute- to ists, requires specific permission antior fee. SIGSCE 98 AtsntaGA USA Copyright /98/2..%5.00 ming books, for, exampe [AndS, B&90, BD9]. This,paper describes, and evauates the features Java has supporting concurrent programming for operating systems and other courses. To hande what is missing (message passing) and to wrap a rendezvous interface around sockets, the author has written a concurrent programming ibrary of casses, avaiabe at ftp://ftp.mcs.drexe.edu/pub/ shertey/concprogsjava.zip and drexe.edu/ shartey/concprogjava/index.htm. What Java Has Java comes with a Thread cass that has many usefu methods: start, stop, yied the CPU, suspend execution, resume execution, seep for some number of miiseconds, and join some other thread when it terminates. Since a threads started in the same Java virtua machine (JVM) share the same address space, they a have access to pubic variabes and there is a need for mutua excusion to avoid ost updates and race conditions. Threads aso need to bock if conditions are not right to proceed unti they are signaed by another thread, caed event or condition synchronization. Note that suspend and resume cannot be used for condition synchronization because a context switch might occur after a thread has decided conditions are not right to proceed but before it has caed suspend; the thread might then miss aater resume intended for it. Students must be discouraged from succumbing to this temptation. For mutua excusion and synchronization, Java provides the monitor as its,buit-in primitive. A Java monitor has synchronized in a its pubic method decarations. The wait, notify, and notifya methods are used for condition synchronization. The ony signaing discipine avaiabe in Java monitors is signa-andcontinue. There are two important properties of this. (1) Since the signaed thread does not get priority to reenter the monitor, the condition that resuted in the signa may no onger be true; other threads may have barged in ahead of it. (2) Since the signaing thread is not required to eave the monitor immediatey after signaing, it can change the state of the monitor after signaing, possiby negating the condition for which the signaed thread is waiting, The impication of these two 247

2 properties is that threads shoud use a oop whie (! condition) wait 0 ; instead of an if check. if (! condition) wait 0 ; This needs to be ceary expained to students. Another important property of Java monitors is that each one has just a singe anonymous condition variabe; a signa cannot be directed to any particuar queue of threads waiting for a specific condition. Either one random waiting thread is reeased with notify or a waiting threads with notifya. The safest programming practice is to wake up a threads with notif ya1 before eaving the monitor, particuary if its state has been changed. Thus, monitor methods shoud have the pattern pubic synchronized type method< > -( whie (! condition) wait 0 ; notifyho,; ; ;,, For exampe, here is a Java server monitor for the five dining phiosopher threads in that we-known operating systems synchronization probem. Note the use of whie waiting oops and not if ya1.?, cass DiningServer,< private int n&f'his = 0; private int[] state = nu; private static fina int ' THINKING :. 0, HUNGRY = I, EATING = 2; pubic DiningServercint numphis) C this.numphis = numphis; state = new int[numphis; for (int i = 0; i,( numphis;.i++) stateci.1 = THINKING; private fina int eft(int i) < return (numphis+i-)%numphis; private fina: int rightcint i> < return (i+)%nuuphis; ' private void test(int k) {. if (stateceft(!=,.eating&&,, '.:, statelk,;= JDINGRY F&, 'I state[right(k)]!= EATING) ', stateck1 = EATING; I pubic synchronized void takeforks(int i> c state Ci = HUNGRY; test(i); whie (state[i]!= EATING) try { wait(); catch (InterruptedException e) I) pubic synchronized void putforks(int i) < state[i] = THINKING; testceft(i test(right(i)); notifya(); At a ower eve, Java provides impicit binary semaphores with initia vaue pne, aso known as critica regions, in the form of synchronized bocks. synchronized (object > ( I In order to execute the statements inside a synchronized bock, the thread must first obtain the ock on the object pointed to by object. Each Java object has an associated ock, so any object can be used for object in a synchronized bock. When an object s ock is reeased by a thread exiting a synchronized bock, the virtua machine chooses a thread at random from those waiting, if any, to acquire the ock.,. Synchronized bocks can be used to enforce mutua excusion during access to shared data by a coection of threads. shared by the threads: Object mutex = neir ObjectO; in each thread: synchronized (mutex) -f. critica section; In fact, a synchronized method in a monitor synchronized is an abbreviation for type iethod ( > I type method (...> ( synchronized (this) (, I / where this refers to the object owning method. Threads can use wait and notify inside synchronized bocks. synchronized (object > 1 :.. object.wait(); i 248

3 object.notify() ; This idea is utiized to create notification objects for Java monitors that are cose in behavior to named condition variabes (remember each Java monitor has ony a singe nameess Fondition variabe). Here is the dining phiosophers server impemented with notification objects. Unfortunatey, the coding is not as cean as if there were true named condition variabes in Java,,a difficuty in teaching this technique to students. The server creates a notification object for each phiosopher. A hungry phiosopher wishing to pick up its forks enters a synchronized bock on its notification object, records its hungry state inside a synchronized bock on,the server (this), and then checks its fork avaiabiity. After eaving the synchronized bock on this, the phiosopher waits, if its forks are not avaiabe, inside its notification object for a signa. A phiosopher reinquishing its forks checks both neighbors to see if either is waiting to eat. The phiosopher sends a signa to a hungry neighbor if both of its for,ks are now avaiabe. : cass DiningServer { private int numf'his = 0; private intc1 state = nu; private ObjectC] notification = nu; private static fina int THINKING = 0, HUNGRY = 1, EATING = 2; pubic DiningServer(int numf'his) { this.numphis = numphis; state = new int[numphis]; for (int i = 0; i < numphis; i++) stateli] = THINKING; notification = new Object@mF'his]; for (int i = 0; i < numphis; i++) notification[i = new ObjectO; private fina int eft(int i) { return (numf'his+i-i)'/,numphis; ) private fina iht right(int i) { return (i+)%numphis; ) private void test(int k) C if (stateceft(!= EATING $8~ statelk] == HUNGRY bt statecright(k)!= EATING) statelk = EATING; -. pubic void tekeforks(int i) { synchronized (notification[i]) { synchronized (this) { state[i] = HUNGRY; test(i); if (stateci1 == EATING) return; try C notificationci.waito; ) catch (InterruptedException e> { pubic void putforks(int i> (. synchronized (this) { " state[i] = THINKING; test(eft(i)); test(right(i)),; ' if (stateceft( == EATING) synchronized (notificationceft(i C notificationceft(i).notify(); if (state[right(i) == EATING) synchronized (n+ification[right(i)]) { notificationcright(i)].notifgo; The instructor must ceary describe the pitfas of signa-and-continue and barging in Java monitors and synchronized bocks. Synchronized bocks are owereve, ike the go to statement; monitors are highereve, ike if, whie, and for statements. The same trade-offs that appy in sequentia programming aso appy in the concurrent case. Notification objects can be very confusing to students if introduced soon after the monitor idea. Nested synchronized bocks and nested monitor invocations are subject to deadock, which students need to understand. The JDK comes with a coection of casses that provide an interface to Berkeey sockets. These are used for network programming and are utiized in the message passing and rendezvous casses written by the author and described beow. The JDK aso incudes a remote procedure ca API, termed remote method invocation (R&II), that aows a thread in one JVM to invoke a method in an object in another JVM that is perhaps on a different computer. To send an object from one JVM to another as an argument of a remote method invocation, object seriaization is used. Thii converts an object into a byte stream that is sent through a socket and converted into a copy of the object on the other end. What Java Does Not Have The Sun Microsystems JDK for Windows 95 uses native threads and so Java threads on this patform are time siced with a quantum of about 50 miiseconds. But Soaris threads are not time siced as of JDK 1.1.1; a thread retains the CPU unti it suspends itsef, yieds, seeps, waits for a ock or signa, joins another thread, or bocks on IO. Aso, Soaris threads in the same JVM cannot yet take advantage of additiona CPUs in a mutiprocessor system. 249

4 However, it is easy to introduce time sicing to Soaris threads. Ah object is instantiated that contains a high priority thread that repeatedy seeps for 50 miiseconds. Each time its seep ends, the currenty executing thread is preempted. When the high priority thread goes back to seep, another thread is aocated the:cpu, most ikey a different one than was preempted. Using time siced threads, the instructor can write Java exampes ofrace conditions, such as a thread being preempted in the midde of manipuating a inked ist, resuting ins a corrupted data structure. Java does not, have genera counting semaphores or binary ones that can be initiaiied to zero. Binary and counting semaphore &sses are straightforward to write as Java monitors and can be made avaiabe to students in a cass ibrary by instructors of concurrent programming. Many semaphore-based programming assignments can then be given, such as an eevator simuation or a starvation-freeiversion of the dining phiosophers. ) Students who have programmed in C++ are accustsmed to using the terminoogy send a message to an object to mean invoking a method in that object. In Java, a threadinvoking.a method in another object temporariy eaves the object it is currenty executing in and executes code in the other object. In concurrent programming; sending a message has a different meaning: a thread sends a message object to another thread executing in some other object and optionay bocks unti the other thread receives the object sent., Since Java does not have message passing, the author has impemented a variety of message passing styes in a cass ibrary for students to use in programming assignments. Each cass impements a maibox or channe that is shared by a coection of threads. Both synchronous (bocking sends), and asynchronous (non-bocking sends) are avaiabe (receives.aways bock). The oneway fow of information from sender.to receiver in synchronous message passing is sometimes caed a simpe rendezvous..i I : I!,.. *I-, 8 shared type:, cass Message ( i shared maibox: SyncMessagePassing maibox = new SyncMessagePassing(); one thread: Message ms = n&i Messdge( > ; send(maibox ms); I - another threadf Mesiage e; t I, mr = (Message) redeive(maibox); Within one JVM, threads share a singe message passing object containing the maibox; for message passing between JVMs, a message passing 0bject containing.a socket is created-in each JVM (the two sockets are connected). The types of information passed in a message are I object references from one thread to another, intra JVM; data type vaues ike int and doube through a pipe, intra JVM; j _ data type vaues ike int and doube through connected sockets, inter JVM; seriaized objects through a pipe, intra JVM; seriaized objects through connected sockets, inter JVM. Thus, distributed programming using a coection of workstations connected to,a oca area network is done in Java with message passing maiboxes based on sockets. Students can write programs to sove arge N- queens probems in parae,on a set of workstations or simuate the dining phiosophers where each phiosopher is executing on its own computer. In cient-server programming, a cient thread transacts with the server thread by sending a message foowed immediatey by a receive that bocks unti the server sends a repy message containing the resuts of the transaction. maibox shared by the cient and server: AsyncMessagePassing maibox = new AsyncMessagePassing(); cient: send(maibox, request) ; repy -= receive (maibox) ; 8 I server: request = receive(maibox) ; compute repy; send(maibox, repy); Another name for this is the extended rendezvous: two threads exchanging information synchronousy. The author s concurrent programming cass ibrary contains an extended rendezvous cass wrapped around a maibox. shared by the cient and server: ExtendedRendezvous er = new ExtendedRenhezvous(); cient: repy = er. cientmakerequestawaitrepy(request); server: request = er. servergetrequest () ; compute repy; er.servermakerepy(repy); 250

5 If the cient and server threads are in the same JVM, one shared rendezvous object is used by the cient to contact the server and the server to repy to the cient. If the cient and server are in different JVMs, perhaps on different computers, two rendezvous objects are used, one by the cient and one by the server, connected through sockets. In the former c&e, the cient and server use object references to exchange information; in the atter case, the objects are seriaized through sockets. These message passing and rendezvous casses support a wide variety of cient-server programming projects. The author beieves these casses are easier for students to use in distributed computing appications than RMI. The author s casses support communication between threads in different JVMs, whereas BMI supports a thread executing a method in a,remote object. Concusions. The author has used Java during the past year to teach concurreit programming to both undergraduates:and graduate students at Drexe University. These students have a previousy programmed in C++ and therefore earn sequentia Java quicky. Using instruct&suppied semaphore, message passing, and rendezvous casses, the students get substantia concurrent programming experience in a anguage they have a heard much about in the popuar press. Their feedback has been uniformy positive. b However, there are a few caveats. Since Java monitors use signa-and-continue and have ony one nameess condition variabe, instrutitors wi need to expam with pseudocode named condition variabes and the sign& and-exit signaing discipine. Students need to code their Java monitors to hande barging. The dangers of using suspend and resume for thread condition synchronization aso need emphasis. So, Afonse [BC96], yes, your Java is ready par98]. References PC961 [CH96] [DeiSO] Pa4 [SG94] [Sta95] [Sun97] [TW97; Bi By&m and Tracy Camp, After You, Afonse: A Mutua Excusion Tookit,,, ACM SIGCSE Buetin, Vo. 28, No. 1, pp , March Gary Corne and Cay S. Horstmann, Core Java, Prentice-Ha, Harvey M. Deite, An &roduction to Operating Systems, second edition, Addison- Wesey, Stephen J. Hartey, Concurrent Programming: The Java Programming Language, Oxford University Press, Abraham Siberschatz and Peter B. Gavin, Operating System Concepts, fourth edition, Addison-Wesey, Wiiam Staings, Operating Systems, second edition, Prentice-Ha, Andrew S. Tanenbaum and Abert S.,Woodhu, Operating Systems: Design and Impementation, second edition, Prentice-Ha, [And911 [AG96] Gregory R. Andrews, Concurrent Programming: Principes and Practice, Benjamin/ Cummings, Ken Arnod and James Gosing, The Java Programming Language, Addison-Wesey, /Ben901 M. Ben-Ari, Principes of Concurrent and Distributed Programming, PrenticeHa, , PD91 Aan Burns and Geoff Davies, Concurrent Progrzunming, Addison-Wesey,