Transcription
0. Course OverviewI. IntroductionII. Fundamental Concepts of Distributed SystemsArchitecture models; network architectures: OSI, Internet and LANs;interprocess communicationIII. Time and Global StatesClocks and concepts of time; Event ordering; Synchronization; Global statesIV. CoordinationDistributed mutual exclusion; Multicast; Group communication, Byzantineproblems (consensus)V. Distribution and Operating SystemsProtection mechanisms; Processes and threads; Networked OS; Distributedand Network File Systems (NFSs)VI. Peer to peer systemsRouting in P2P, OceanStore, Bittorrent, OneSwarm, Ants P2P, Tor, Freenet,I2PVII. SecuritySecurity concepts; Cryptographic algorithms; Digital signatures;Authentication; Secure SocketsDistributed Systems Fall 2009V 1
Operating Systems for Distributed SystemsNetwork Operating Systemone instance running per computer in a networkoperating system manages local resources as well as access to networkinfrastucturenetwork file systemsrlogintelnetexamplesWindows (98/NT/2000.)Unix (Solaris, .)LinuxDistributed Operating Systemsingle image systemcomplete transparency for the user where programs runOS has control over all nodes in systemnot practically in usecompatability with existing applicationsemulations offer very bad performanceexampleAmoeba (Tannenbaum et al.)Distributed Systems Fall 2009V 2
Operating Systems for Distributed SystemsGeneral Architecture in Practical Usenetwork operating system middleware layerApplications, servicesMiddlewareOS: kernel,libraries &serversOS1Processes, threads,communication, .OS2Processes, threads,communication, .Computer &network hardwareComputer &network hardwareNode 1Node 2 Addison-Wesley Publishers 2000Distributed Systems Fall 2009V 3Platform
Operating Systems for Distributed SystemsDesiderata for Network Operating Systemsprovide support for middleware layer to work effectivelyencapsulationprovide transparent service interface to resources of the computerprotectionprotect resources from illegitimate accessconcurrent processingusers/clients may share resources and access concurrentlyDistributed Systems Fall 2009V 4
Operating Systems for Distributed SystemsProcesssoftware in executionunit of resource management for operating systemexecution environmentaddress spacethread synchronization and communication resources (e.g.,semaphores, sockets)computing resources (file systems, windows, etc.)threadsschedulable activities attached to processesarise from the need for concurrent activities sharing resources withinone processconcurrent input/output with problem computationservers: concurrent processing of client requests, each requesthandled by one threadprocesses vs. threadsthreads are “lightweight” processesprocesses expensive to create, threads easier to create and destroyprocess instantiationone thread will be instantiated as well, may instantiate offspringsDistributed Systems Fall 2009V 5
Operating Systems for Distributed SystemsProcess managerCommunicationmanagerThread managerMemory managerSupervisorCore Operating System Functionalityprocess managermaintains processes (creation, termination)thread managercreation, synchronization and schedulingcommunication managercommunication between threadsin different processeson different computersDistributed Systems Fall 2009V 6 Addison-Wesley Publishers 2000
Operating Systems for Distributed SystemsProcess managerCommunicationmanagerThread managerMemory managerSupervisor Addison-Wesley Publishers 2000Core Operating System Functionalitymemory managermanagement of physical and virtual memorysupervisordispatching of interrupts, system call traps and exceptionscontrol of memory management unit and hardware cachesprocessor and floating point unit register manipulationsDistributed Systems Fall 2009V 7
Protection MechanismsProtection against illegitimate accessclients performing operations need to have right to do soonly specified operations may be performed on an objectKernelcore part of operating system that has complete access rights to anyresourceprocessor modesusersupervisorkernel always executes in supervisor modesome operations are only allowed in supervisor modekernel sets up address spaces to protect against illegitimate memoryaccessescollection of ranges of virtual addresses (memory locations)process cannot access memory locations outside it’s address spaceswitching between processes entails switching of address spacesmay involve non negligible amount of work, performance implicationsDistributed Systems Fall 2009V 8
Processes and ThreadsAddress Spacesregions of memory accessible tothreads of that processsubdivided into regionslowest address and lengthread/write/execute permissionsfor threads in processdirection of growthstackfor subroutinessometimes one stack region perthreadtextregion to map files into memoryshared regionregions of virtual memorymapped to identical physicalmemory for different processesenables inter t0 Addison-Wesley Publishers 2000Distributed Systems Fall 2009V 9
Processes and ThreadsProcess creationchoice of target host (only for distributed operating systems)creation of an execution environmentcontents of newly allocated address spaceinitialized “empty”initialized as a (partial) copy of parent’s address spaceexample: Unix fork command: child process shares text regionwith parent, has own copies of stack and heap (an extensionallows choices which regions are shared, and which ones areinherited)copy on write (in Mach operating system)inherited region initially sharedonly when one process attempts to write, an interrupt handlerwill start copying the shared region to a new instanceA's pagetable Addison-Wesley Publishers 2000Distributed Systems Fall 2009SharedframeB's pagetablea) Before writeb) After writeV 10
Processes and ThreadsPerformance considerations: handling server requestsprocessing: 2 msIO delay (no caching): 8 mssingle thread10 ms per requests, 100 requests per secondtwo threads (no caching)8 ms per request, 125 requests per secondtwo threads and caching75% hit ratemean IO time per request: 0.25 * 8ms 2ms500 requests per secondincreased processing time per request: 2.5 ms400 requests per secondDistributed Systems Fall 2009V 11
Processes and ThreadsThread 2 makesrequests to serverReceipt &queuingThread 1generatesresultsT1RequestsInput-outputN threadsClientServerworkersI/Oper-connection threadsremoteobjectsremoteobjectsper-object threadsI/Oremoteobjects Addison-Wesley Publishers 2000a. Thread-per-requestb. Thread-per-connectionc. Thread-per-objectThreads and Serversworker poolpool of server threads serves requests in queuepossible to maintain priorities per queuethread per requestthread lives only for the duration of request handlingmaximizes throughput (no queuing)expensive overhead for thread creation and destructionDistributed Systems Fall 2009V 12
Processes and ThreadsThread 2 makesrequests to serverReceipt &queuingThread 1generatesresultsT1RequestsInput-outputN threadsClientServerworkersI/Oper-connection threadsremoteobjectsremoteobjectsper-object threadsI/Oremoteobjects Addison-Wesley Publishers 2000a. Thread-per-requestb. Thread-per-connectionc. Thread-per-objectThreads and Serversthread per connection/per objectcompromise solutionno overhead for creation/deletion of threadsrequests may still block, hence throughput is not maximalDistributed Systems Fall 2009V 13
Processes and ThreadsExecution environmentAddress space tablesCommunication interfaces, open filesThreadSaved processor registersPriority and execution state (such asBLOCKED)Software interrupt handling informationSemaphores, other synchronizationobjectsList of thread identifiersExecution environment identifierPages of address space resident in memory; hardware cache entries Addison-Wesley Publishers 2000Threads vs. multiple processes/execution environmentscreating a new thread is much less expensive than creating new executionenvironmentcreating new thread:allocate region of thread's stack andset registers and processor statuscreating new execution environmentcreate address space table, communication interfacesnew process starts with "empty" cache, therefore more cache missesthan for new threadexperiment: new process under Unix 11ms, new thread under Topazkernel: 1 msDistributed Systems Fall 2009V 14
Processes and ThreadsExecution environmentAddress space tablesCommunication interfaces, open filesThreadSaved processor registersPriority and execution state (such asBLOCKED)Software interrupt handling informationSemaphores, other synchronizationobjectsList of thread identifiersExecution environment identifierPages of address space resident in memory; hardware cache entries Addison-Wesley Publishers 2000Threads vs. multiple processes/execution environmentsswitching between threads more efficient than switching between processesthreadsscheduling (deciding which thread to run next)context switching (saving processor's register state, loading newregister contents)domain transitionsif new thread is member of a different execution environmentcache misses more severe than in domain switchingexperimental resultsprocess switch in Unix: 1.8ms, thread switch in Topaz: 0.4 msDistributed Systems Fall 2009V 15
Processes and ThreadsExecution environmentAddress space tablesCommunication interfaces, open filesThreadSaved processor registersPriority and execution state (such asBLOCKED)Software interrupt handling informationSemaphores, other synchronizationobjectsList of thread identifiersExecution environment identifierPages of address space resident in memory; hardware cache entries Addison-Wesley Publishers 2000Threads vs. multiple processes/execution environmentsEasy sharing of data amongst processes in one execution environmentno need for message passingcommunication via shared memoryNo protection against malevolent threadsone thread can access other thread's data, unless a type safeprogramming language is being usedDistributed Systems Fall 2009V 16
Processes and ThreadsJava Thread classThread(ThreadGroup group, Runnable target, String name)Creates a new thread in the SUSPENDED state, which will belong to group and beidentified as name; the thread will execute the run() method of target.setPriority(int newPriority), getPriority()Set and return the thread’s priority.run()A thread executes the run() method of its target object, if it has one, and otherwise itsown run() method (Thread implements Runnable).start()Change the state of the thread from SUSPENDED to RUNNABLE.sleep(int millisecs)Cause the thread to enter the SUSPENDED state for the specified time.yield()Enter the READY state and invoke the scheduler.destroy()Destroy the thread. Addison-Wesley Publishers 2000Distributed Systems Fall 2009V 17
Processes and ThreadsThread Groupsevery thread belongs to one group, assigned at thread creation timethread groups useful to shield various applications running in parallel on oneJava Virtual machinethread in one group may not interrupt thread in another groupe.g., an application may not interrupt the windowing (AWT) threadJava Thread Synchronizationeach thread’s local variables and methods are private to itthread has own stackthread does not have private copies of static (class) variables or objectinstance variablesmutual exclusion via monitor conceptabstract data type first implemented in Adain Java: synchronized keywordany object can only be accessed through one invokation of any of itssynchronized methodsan object can have synchronized and non synchronized methodsexamplesynchronized addTo() and removeFrom() methods to serializerequests in worker pool exampleDistributed Systems Fall 2009V 18
Processes and ThreadsJava Thread Synchronizationthreads can be blocked and woken upthread awaiting a certain condition calls an object’s wait() methodother thread calls notify() or notifyAll() to awake one or allblocked threadsexampleworker thread discovers no requests to be processedcalls wait() on instance of Queuewhen IO thread adds request to queuecalls notify() method of queue to wake up worker Addison-Wesley Publishers 2000thread.join(int millisecs)Blocks the calling thread for up to the specified time until thread has terminated.thread.interrupt()Interrupts thread: causes it to return from a blocking method call such as sleep().object.wait(long millisecs, int nanosecs)Blocks the calling thread until a call made to notify() or notifyAll() on object wakesthe thread, or the thread is interrupted, or the specified time has elapsed.object.notify(), object.notifyAll()Wakes, respectively, one or all of any threads that have called wait() on object.Distributed Systems Fall 2009V 19
Architecture of Networked Operating SystemsS4.S1S1Key:Server:S2S3S2S3S4.Monolithic KernelMicrokernelKernel code and data:Dynamically loaded server program: Addison-Wesley Publishers 2000Monolithic Kernel vs. Microkernelgoal: separation of concernse.g., separate resource management mechanisms from policiesexample: separate context switching mechanism from policy decidingwhich process to schedule nextpossible architecture: kernel performs only basic mechanisms, policiesloaded dynamically by invoking services outside kernelmonolithic kernelall essential functions implemented inside kernelexample: Unixmicrokernelonly basic functionality in kernel, services dynamically loadedservers run in user (unprivileged) modeDistributed Systems Fall 2009V 20
Architecture of Networked Operating upportsubsystemOS emulationsubsystem.MicrokernelHardwareThe microkernel supports middleware via subsystems Addison-Wesley Publishers 2000Microkernel and Middlewaremicrokernel a layer between hardware, services and middlewarefor performance reasons, middleware may directly access microkernelroutinesotherwise, access throughprogramming language APIsOS emulation callse.g., Unix calls emulated on Mach distributed operating systemDistributed Systems Fall 2009V 21
Architecture of Networked Operating SystemsS4.S1S1Key:Server:S2S3S2S3S4.Monolithic KernelKernel code and data:MicrokernelDynamically loaded server program: Addison-Wesley Publishers 2000Monolithic Kernel vs. Microkernelmicrokernel basedadvantageextensibilitymaintainability (modularity)small kernel likely to be bug freedisadvantageinvoking services involves context switchesessential system services executing in user modemonolithic kerneladvantageefficiencydisadvantageall services execute in supervisor modeDistributed Systems Fall 2009V 22
File SystemsFile Systemoperating system interface to disk storageFile System Attributes (Metadata)File lengthCreation timestampRead timestampWrite timestampAttribute timestampReference countOwnerFile typeAccess control list Addison-Wesley Publishers 2000Distributed Systems Fall 2009V 23
File SystemsOperations on Unix File Systemfiledes open(name, mode)filedes creat(name, mode)status close(filedes)count read(filedes, buffer, n)count write(filedes, buffer, n)pos lseek(filedes, offset,whence)status unlink(name)status link(name1, name2)status stat(name, buffer)Opens an existing file with the given name.Creates a new file with the given name.Both operations deliver a file descriptor referencing the openfile. The mode is read, write or both.Closes the open file filedes.Transfers n bytes from the file referenced by filedes to buffer.Transfers n bytes to the file referenced by filedes from buffer.Both operations deliver the number of bytes actually transferredand advance the read-write pointer.Moves the read-write pointer to offset (relative or absolute,depending on whence).Removes the file name from the directory structure. If the filehas no other names, it is deleted.Adds a new name (name2) for a file (name1).Gets the file attributes for file name into buffer. Addison-Wesley Publishers 2000Distributed Systems Fall 2009V 24
Distributed File SystemDistributed File Systemfile system emulating non distributed file system behaviour on a physicallydistributed set of files, usually within an intranetrequirementstransparencyaccess transparency: hide distributed nature of file system byproviding a single service interface for local and distributed filesprograms working with a non distributed file system should workwithout major adjustments on a distributed file systemlocation transparency: uniform, location independent name spacemobility transparency: file specifications will remain invariant if a fileis physically moved to a different location within the dfsperformance transparency: load increase within normal boundsshould allow a client to continue to receive satisfactory performancescaling transparency: expansion by incremental growthallow concurrent accessallow file replicationtolerate hardware and operating system heterogeneityDistributed Systems Fall 2009V 25
Distributed File SystemDistributed File Systemrequirementsfault tolerance: continue to provide correct service in the presence ofcommunication or server faultsat most once semantics for file operationsat least once semantics for indempotent file operationsreplication (stateless, so that servers can be restarted after failure)consistencyone copy update semanticsall clients see contents of file identically as if only one copy offile existedif caching is used: after an update operation, no program canobserve a discrepancy between data in cache and stored datasecurityaccess controlclient authenticationefficiencylatency of file accessesscalability (e.g., with increasing number of concurrent users)Distributed Systems Fall 2009V 26
ArchitectureClient computerServer computerDirectory serviceApplication ApplicationprogramprogramFlat file serviceClient moduleFlat File Service Addison-Wesley Publishers 2000performs file operationsuses “unique file identifiers” (UFIDs) to refer to filesflat file service interfaceRPC based interface for performing file operationsnot normally used by application level programsDirectory Servicemapping of UFIDs to “text” file names, and vice versaClient Moduleprovides API for file operations available to application programDistributed Systems Fall 2009V 27
ArchitectureRead(FileId, i, n) - Data— throws BadPositionWrite(FileId, i, Data)— throws BadPositionCreate() - FileIdDelete(FileId)GetAttributes(FileId) - AttrSetAttributes(FileId, Attr)If 1 i Length(File): Reads a sequence of up to n itemsfrom a file starting at item i and returns it in Data.If 1 i Length(File) 1: Writes a sequence of Data to afile, starting at item i, extending the file if necessary.Creates a new file of length 0 and delivers a UFID for it.Removes the file from the file store.Returns the file attributes for the file.Sets the file attributes (only those attributes that are notshaded in ). Addison-Wesley Publishers 2000Flat File Service Interfacecomparison with Unixevery operation can be performed immediatelyUnix maintains file pointer, reads and writes start at the file pointerlocationadvantages: fault tolerancewith the exception of create, all operations are indempotentcan be implemented as a stateless, replicated serverDistributed Systems Fall 2009V 28
ArchitectureAccess Controlat the server in dfs, since requests are usually transmitted via unprotectedRPC callsmechanismsaccess check when mapping file name to UFID, returning cryptographic“capability” to requester who uses this for subsequent requestsaccess check at server with every file system operationHierachical File Systemfiles organized in treesreference by pathname filenameFile Groupsgroups of files that can be moved between serversfile cannot change group membershipin Unix: filesystemidentification: must be unique in networkIP address of creating hostdate of creationDistributed Systems Fall 2009V 29
SUN Network File SystemClient computerApplication ApplicationprogramprogramUNIX kernelUNIX kernelVirtual file systemLocalRemoteUNIXfilesystemOtherfile systemUNIXsystem callsServer computerVirtual file systemNFSclientNFSserverNFSprotocolArchitecture of NFS Version 3UNIXfilesystem Addison-Wesley Publishers 2000access transparencyno distinction between local and remote filesvirtual file system keeps track of locally and remotely availablefilesystemsfile identifiers: file handlesfilesystem identifier (unique number allocated at creation time)i node numberi node generation number (because i node numbers are reused)Distributed Systems Fall 2009V 30
SUN Network File SystemSelected NFS Server Operations I lookup(dirfh, name) - fh, attrReturns file handle and attributes for the file name in the directorydirfh.create(dirfh, name, attr) - newfh, attrCreates a new file name in directory dirfh with attributes attr andreturns the new file handle and attributes.remove(dirfh, name) statusRemoves file name from directory dirfh.getattr(fh) - attrReturns file attributes of file fh. (Similar to the UNIX stat systemcall.)setattr(fh, attr) - attrSets the attributes (mode, user id, group id, size, access time andmodify time of a file). Setting the size to 0 truncates the file.read(fh, offset, count) - attr, dataReturns up to count bytes of data from a file starting at offset.Also returns the latest attributes of the file.write(fh, offset, count, data) - attrWrites count bytes of data to a file starting at offset. Returns theattributes of the file after the write has taken place.rename(dirfh, name, todirfh, toname) Changes the name of file name in directory dirfh to toname in- statusdirectory to todirfh.link(newdirfh, newname, dirfh, name) Creates an entry newname in the directory newdirfh which refers to- statusfile name in the directory dirfh. Addison-Wesley Publishers 2000Distributed Systems Fall 2009V 31
SUN Network File SystemSelected NFS Server Operations II symlink(newdirfh, newname, string) Creates an entry newname in the directory newdirfh of type- statussymbolic link with the value string. The server does not interpretthe string but makes a symbolic link file to hold it.readlink(fh) - stringReturns the string that is associated with the symbolic link fileidentified by fh.mkdir(dirfh, name, attr) - newfh, attrCreates a new directory name with attributes attr and returns thenew file handle and attributes.rmdir(dirfh, name) - statusRemoves the empty directory name from the parent directory dirfh.Fails if the directory is not empty.readdir(dirfh, cookie, count) - entriesReturns up to count bytes of directory entries from the directorydirfh. Each entry contains a file name, a file handle, and an opaquepointer to the next directory entry, called a cookie. The cookie isused in subsequent readdir calls to start reading from the followingentry. If the value of cookie is 0, reads from the first entry in thedirectory.statfs(fh) - fsstatsReturns file system information (such as block size, number offree blocks and so on) for the file system containing a file fh. Addison-Wesley Publishers 2000Distributed Systems Fall 2009V 32
SUN Network File SystemAccess Control/AuthenticationNFS requests transmitted via Remote Procedure Calls (RPCs)clients send authentication information (user / group IDs)checked against access permissions in file attributespotential security loopholeany client may address RPC requests to server providing another client’sidentification informationintroduction of security mechanisms in NFSDES encryption of user identification informationKerberos authenticationDistributed Systems Fall 2009V 33
SUN Network File SystemServer big jon bobvmunixServer 2mountRemotestudentsxstaff.mountusersjim ann jane joe Addison-Wesley Publishers 2000Mounting of Filesystemsmaking remote file systems available to a local client, specifying remote hostname and pathnamemount protocol (RPC based)returns file handle for directory name given in requestlocation (IP address and port number) and file handle are passed toVirtual File system and NFS clienthard mounted (mostly used in practice)client suspended until operation completedapplication may not terminate gracefully in failure situationssoft mountederror message returned after small number of retriesDistributed Systems Fall 2009V 34
SUN Network File SystemCaching in server and client indispensable to achieve necessaryperfomanceServer cachingdisk caching as in non networked file systemsread operations: unproblematicwrite operations: consistency problemswrite through cachingstore updated data in cache and on disk before sending reply toclientrelatively inefficient if frequent write operations occurcommit operationcaching only in cache memorywrite back to disk only when commit operation for file receivedDistributed Systems Fall 2009V 35
SUN Network File SystemCaching indispensable to achieve necessary perfomanceClient cachingcaching of read, write, getattr, lookup and readdir operationspotential inconsistency: the data cached in client may not be identical tothe same data stored on the servertime stamp based scheme used in polling server about feshness of adata object (presumption of synchronized global time, e.g., through NTP)Tc: time cache was last validatedTmclient/server: time when block was last modified at the server asrecorded by client/servert: freshness intervalfreshness condition(T Tc t) (Tmclient TMserver)if (T Tc t) (can be determined without server access), thenentry presumed to be validif not (T Tc t), then TMserver needs to be obtained by agetattr callif Tmclient TMserver, then data presumed valid, else obtain datafrom server and update Tmclientnote: scheme does not guarantee consistency, since recent updates mayDistributed Systems beFall 2009invisible, one copy updateVsemanticsonly approximated 36
SUN Network File SystemCaching indispensable to achieve necessary perfomanceClient cachingperfomance factors: how to reduce server traffic, in particular forgetattrreceipt of TMserver, then update all Tmclient values related to data objectderived from the same filepiggyback current attribute values on results of every file operationadaptive algorithm for tt too short: many server requestst too large: increased chance of inconsistenciestypical values: 3 to 30 secs for files, 30 to 60 secs for directoriesin Solaris, t is adjusted according to frequency of file updatesDistributed Systems Fall 2009V 37
SUN Network File SystemCaching indispensable to achieve necessary perfomanceClient caching write operationsmark modified cache page as “dirty” and schedule page to be flushed toserver (asynchronously)flush happens with closing of file, when sync is issued,or when asynchronous block input output (bio) daemon is used andactivewhen read, then read ahead: when read occurs, bio daemonsends next file blockwhen write, then bio daemon will send block asynchronouslyto serverbio daemons: performance measure reducing probability that clientblocks waiting for* read operations to return, or* write operations to be committed at the serverDistributed Systems Fall 2009V 38
Andrew File SystemAndrew File System (AFS)started as a joint effort of Carnegie Mellon University and IBMtoday basis for DCE/DFS: the distributed file system included in the OpenSoftware Foundations’s Distributed Computing Environmentsome UNIX file system usage observations, as pertaining to cachinginfrequently updated shared files and local user files will remain valid forlong periods of time (the latter because they are being updated onowners workstations)allocate large local disk cache, e.g., 100 MByte, that can provide a largeenough working set for all files of one user such that the file is still in thiscache when used next timeassumptions about typical file accesses (based on empirical evidence)usually small files, less than 10 Kbytesreads much more common than writes (appr. 6:1)usually sequential access, random access not frequently founduser locality: most files are used by only one userburstiness of file references: once file has been used, it will be usedin the nearer future with high probabilityDistributed Systems Fall 2009V 39
Andrew File SystemAndrew File System (AFS)design decisions for AFSwhole file serving: entire contents of directories and files transfered fromserver to client (AFS 3: in chunks of 64 Kbytes)whole file caching: when file transfered to client it will be stored on thatclient’s local diskDistributed Systems Fall 2009V 40
Andrew File SystemAFS architecture:WorkstationsVenus, network and ViceServersUser VenusprogramViceUNIX kernelUNIX kernelUser VenusprogramUNIX kernelNetworkViceVenusUserprogramUNIX kernelUNIX kernel Addison-Wesley Publishers 2000AFS system call intercept, handlingby VenusWorkstationUserprogramVenusUNIX filesystem callsNon-local fileoperationsUNIX kernelUNIX file systemLocaldiskDistributed Systems Fall 2009 Addison-Wesley Publishers 2000V 41
Andrew File SystemImplementation of file system calls callbacks and callbackpromisesUser processopen(FileName,mode)UNIX kernelVenusIf FileName refers to afile in shared file space,Check list of files inpass the request tolocal cache. If notVenus.present or there is novalid callback promise,send a request for thefile to the Vice serverthat is custodian of thevolume containing thefile.Open the local file andreturn the filedescriptor to theapplication.Place the copy of thefile in the local filesystem, enter its localname in the local cachelist and return the localname to UNIX.NetViceTransfer a copy of thefile and a callbackpromise to theworkstation. Log thecallback promise.read(FileDescriptor, Perform a normalBuffer, length) UNIX read operationon the local copy.write(FileDescriptor, Perform a normalBuffer, length) UNIX write operationon the local copy.close
Java Virtual machine thread in one group may not interrupt thread in another group e.g., an application may not interrupt the windowing (AWT) thread Java Thread Synchronization each thread's local variables and methods are private to it thread has own stack
