Distributed Systems LEEC (2005/06 – 2º Sem.)

Processes

João Paulo Carvalho

Universidade Técnica de Lisboa / Instituto Superior Técnico Outline • Processes and Threads –Overview – Processes, threads and fibers – Light weight processes • Client and Server Processes • Code migration • Software Agents • Case Studies

J.P. Carvalho Sistemas Distribuídos 2005/2006 2 Processes Review • Multiprogramming versus multiprocessing • Kernel data structure: process control block (PCB) • Each process has an address space – Contains code, global and local variables.. • Process state transitions • Uniprocessor scheduling algorithms – Round-robin, shortest job first, FIFO, lottery scheduling, EDF • Performance metrics: throughput, CPU utilization, turnaround time, response time, fairness

J.P. Carvalho Sistemas Distribuídos 2005/2006 3 Processes (2)

Review - Scheduling • Priority queues: multiples queues, each with a different priority – Use strict priority scheduling – Example: page swapper, kernel tasks, real-time tasks, user tasks • Multi-level feedback queue – Multiple queues with priority – Processes dynamically move from one queue to another • Depending on priority/CPU characteristics – Gives higher priority to I/O bound or interactive tasks – Lower priority to CPU bound tasks – Round robin at each level

J.P. Carvalho Sistemas Distribuídos 2005/2006 4 Processes and Threads • Processes – Typically independent – Carry considerable state information – Have separate address spaces – Interact only through system-provided inter-process communication mechanisms • Threads – Share the state information of a single process – Share memory and other resources directly • Context switching between threads in the same process is typically faster than context switching between processes. – Systems like Windows XP and OS/2 are said to have "cheap" threads and "expensive" processes, while in other operating systems there is not so big a difference.

J.P. Carvalho Sistemas Distribuídos 2005/2006 5 Processes and Threads(2) • Multi-threaded program advantage: – Operates faster on computer systems that have multiple CPUs, CPUs with multiple cores, or across a cluster of machines • Why? – Because the threads of the program naturally lend themselves for truly concurrent execution • The programmer needs to be careful to avoid race conditions, and other non-intuitive behaviors • In order for data to be correctly manipulated, threads will often need to rendezvous in time in order to process the data in the correct order • Threads may also require atomic operations (often implemented using semaphores) in order to prevent common data from being simultaneously modified, or read while in the process of being modified. Careless use of such primitives can lead to deadlocks

J.P. Carvalho Sistemas Distribuídos 2005/2006 6 Processes and Threads (3) • Thread Scheduling: – Preemptive multithreading • Allows the operating system to determine when a context switch should occur – Disadvantage: the system may make a context switch at an inappropriate time – Cooperative multithreading • The threads themselves relinquish control once they are at a stopping point – Disadvantage: can create problems if a thread is waiting for a resource to become available).

J.P. Carvalho Sistemas Distribuídos 2005/2006 7 Why use Threads?

• Large multiprocessors need many computing entities (one per CPU) • Threads can execute in parallel on multiprocessors • Switching between processes incurs high overhead. By using threads, an application can avoid per-process overheads • Thread creation and deletion are also cheaper than processes • Threads have full access to a process address space (easy sharing) • Threads retain the idea of sequential processes with blocking system calls, and yet achieve parallelism • Software engineering perspective – Applications are easier to structure as a collection of thread where each thread performs several [mostly independent] tasks

J.P. Carvalho Sistemas Distribuídos 2005/2006 8 Thread Management • Creation and deletion of threads – Static versus dynamic • Critical sections – Synchronization primitives: blocking, spin-lock (busy-wait) – Condition variables • Global thread variables • Kernel versus user-level threads

J.P. Carvalho Sistemas Distribuídos 2005/2006 9 User-level Threads User-Level Threads, aka Fibers • Threads managed by a threads library – Kernel is unaware of presence of threads • Advantages: – No kernel modifications needed to support threads – Efficient: creation/deletion/switches don’t need system calls – Flexibility in scheduling: library can use different scheduling algorithms, can be application dependent • Disadvantages – Need to avoid blocking system calls (a thread blocks the entire process) – Threads compete for resources within a process – Do not take advantage of multiprocessors (no real parallelism)

J.P. Carvalho Sistemas Distribuídos 2005/2006 10 User-level Threads (2)

User-level Thread Example

J.P. Carvalho Sistemas Distribuídos 2005/2006 11 Kernel-level Threads Kernel Level Threads • Kernel aware of the presence of threads – Blocked threads do not block other threads in the same process – Better but more expensive scheduling decisions – Better for multiprocessors, more overheads for uniprocessors

J.P. Carvalho Sistemas Distribuídos 2005/2006 12 Light-Weight Processes

LWP •Goal:Implement “fibers” that do not block the associated process – NOTE: Many systems (e.g. Java), do not make a distinction between Kernel Threads and LWP (Kernel Threads are implemented as LWP) • Several LWPs per process • Multithreaded applications – create multiple threads, assign threads to LWPs (one-one, many-one, many-many) • Each LWP, when scheduled, searches for a runnable thread on a shared thread table (two-level scheduling) – Shared thread table: no kernel support needed • If a LWP thread blocks on a system call, switch to kernel mode and, if possible, switch OS context to another LWP of the same process

J.P. Carvalho Sistemas Distribuídos 2005/2006 13 Light-Weight Processes(2)

LWP Example

J.P. Carvalho Sistemas Distribuídos 2005/2006 14 P T F Example (extracted from Wikipedia)

N N N A program running on DOS. The program can only do one thing at a time.

Windows 3.1 running on top of DOS. All Windows programs are run within a single process, so the programs can corrupt each N N Y other's memory space. A poorly written program could corrupt data it didn't own, causing the infamous General Protection Fault, or neglect to yield the processor, resulting in a hung system. Amiga OS's original implementation. The operating system had full thread support, allowing multiple applications to run independently of each other which are scheduled by the kernel. The lack of process support resulted in a more efficient system N Y N (by avoiding the overhead of memory protection), with the price that application bugs could easily crash the entire computer. Many commercial RTOSes, such as vxWorks, also support this model. Mac OS 9 supported fibers through Apple's Thread Manager and threads through Apple's Multiprocessing Services, which N Y Y works with the nanokernel intoduced in Mac OS 8.6 to provide thread support, but still use the MultiFinder's way of managing applications. Most early implementations of Unix. The operating system could run more than one program at a time, and programs were protected from each other. If a program behaved badly, it could crash its process ending that instance of the program without Y N N disrupting the operating system or other programs. However, due to this protection, sharing information between programs was error-prone (using techniques like shared memory) and expensive (using techniques like message passing). Performing any tasks asynchronously required an expensive fork() system call. Sun OS before Solaris. Sun OS is Sun Microsystem's version of Unix. Sun OS implemented "green threads" in order to allow a single process to asynchronously perform multiple tasks such as playing a sound, repainting a window, and responding to user Y N Y events such as clicking the stop button. Although processes were pre-emptively scheduled, the "green threads" or fibers were co-operatively multitasked. Often this model was used before real threads were implemented. This model is still used in microcontrollers and embedded devices. This is the most common case for applications running on Windows NT 3.51 SP3+, Windows 2000, Windows XP, Mac OS X, Linux, and other modern operating systems. Although each of these operating systems allows the programmer to implement fibers or use a fiber library, most programmers do not use fibers in their applications. The programs are multithreaded and run Y Y N inside a multitasking operating system, but perform no user-level context switching. On the typical home computer, most running processes have two or more threads. A few processes will have a single thread. Usually these processes are services running without user interaction. Typically there are no processes using fibers. Almost all operating systems after 1995 fall into this category. The use of threads to perform concurrent operations is the most Y Y Y commonJ.P. choice, Carvalho although there are also multi-process Sistemas andDistribuídos multi-fiber applications. 2005/2006 Threads are used, for example, to enable 15 a program to render its graphical user interface while waiting for input from the user or performing a task like spell checking. Threads Implementations • There are many different and incompatible implementations of threading, including both kernel-level and user-level implementations • Note that fibers can be implemented without operating system support, although some operating systems or libraries provide explicit support for them – E.g.: recent versions of Microsoft Windows, like Microsoft SQL Server 2000's user mode scheduler, running in fiber mode, support a fiber API for applications that want to gain performance improvements by managing scheduling themselves, instead of relying on the kernel scheduler (which may not be tuned for the application)

J.P. Carvalho Sistemas Distribuídos 2005/2006 16 Threads Implementations (2) • Kernel-level implementation examples – Light Weight Kernel Threads in various BSDs – M:N threading (in BSDs) • User-level implementation examples – GNU Portable Threads – FSU Pthreads – Apple Computer's Thread Manager • Kernel/User level and Hybrid implementation examples – Native POSIX Thread Library for Linux, an implementation of the POSIX Threads (pthreads) standard – Pthreads-win32, POSIX Thread for Windows – Scheduler activations (i.e. NetBSD M:N threads)

J.P. Carvalho Sistemas Distribuídos 2005/2006 17 Threads Implementations (3) Notes on some thread implementations • Posix Threads (pthreads) – Widely used threads package – Conforms to the Posix standard – Sample calls: pthread_create,… – Typically used in C/C++ applications and available for several OS – Can be implemented as user-level, kernel-level or via LWPs • Java Threads – Native thread support built into the language – Threads are scheduled by the JVM J.P. Carvalho Sistemas Distribuídos 2005/2006 18 Client and Server Processes Client Organization • Most client processes are multi-threaded (or have at least 2 threads): – The user/remote server interface – One or more threads that perform local processing and communication facilities (form filling, simple or more complex computations involving data, etc. – see slide 2.36) Server Organization • Iterative: the server sequentially handles itself the request and, if needed returns a response • Concurrent: the server passes the request to a separate thread or to another process and immediately handles or waits the next incoming request (e.g: a multithreaded server; a UNIX server that forks a new process for each incoming request)

J.P. Carvalho Sistemas Distribuídos 2005/2006 19 Multi-threaded Clients Example: Web Browsers • Browsers such as IE are multi-threaded • Besides providing for a user interface, such browsers can perform multiple simultaneous tasks allowing data display before entire document is downloaded: – Fetch main HTML page, activate separate threads for other parts – Each thread sets up a separate connection with the server • Uses blocking calls – Each part (gif image) fetched separately and in parallel – Advantage: connections can be setup to different sources • Ad server, image server, web server…

J.P. Carvalho Sistemas Distribuídos 2005/2006 20 Multi-threaded Servers

Example: Apache web server • Apache web server: pool of pre-spawned worker threads – Dispatcher thread waits for requests – For each request, choose an idle worker thread – Worker thread uses blocking system calls (that do not block the process) to service web request

J.P. Carvalho Sistemas Distribuídos 2005/2006 21 Multi-threaded Servers (2)

Example: Object Servers • Although an object server does not provide a specific service itself (specific services are implemented by objects residing in the server), the server provides the means to invoke local objects based on requests from remote clients – Main advantage: it’s easy to change services by simply adding and/or removing objects • Different implementation options: – A separate thread is assigned for each object – A separate thread is used for each invocation request • E.g: CORBA (will be studied later)

J.P. Carvalho Sistemas Distribuídos 2005/2006 22 Code and Process Migration

Reasons to Migrate Code and Processes 1. Performance: Improved system-wide performance due to better resource utilization – Move processes from heavily-loaded to lightly-loaded machines (e.g. Condor) – Process data close to where data reside and ship parts of client application to server instead of data from server to client • even if server is more loaded, it might be preferable to execute a client process in the server if it avoids moving large amounts of data through the network (e.g. a client application that needs to do many operations on a large database) – Exploit parallelism (e.g. agent-based web searches)

J.P. Carvalho Sistemas Distribuídos 2005/2006 23 Code and Process Migration (2)

Reasons to Migrate Code and Processes (cont.) 2. Flexibility: Dynamic distributed system configuration – Clients don’t need preinstalled software, simply download on demand – The client first fetches the necessary software, and then invokes the server

J.P. Carvalho Sistemas Distribuídos 2005/2006 24 Code and Process Migration (3) Migration Models • Process = code segment + resource segment + execution segment – Code segment: contains the program instructions – Resource segment: contains references to external resources needed by the process (e.g. files, printers, devices, other processes, etc.) – Execution segment: contains the current execution state of the process (Program Counter, private data, stack, etc.) • Mobility Types: – Weak mobility: Only the code and eventually some initialization data is migrated • The program always starts from its initial state • Simplicity: single requirement is that the receiver must be able to execute the code • E.g: Java Applets – Strong mobility: The execution segment can also be transferred • A running program can be stopped, moved to another machine and resume execution • Much more powerful but obviously much more harder to implement • E.g: D’Agents J.P. Carvalho Sistemas Distribuídos 2005/2006 25 Code and Process Migration (4)

Migration Models (cont.) • Sender vs. Receiver-initiated migration – Sender initiated: • Code is with sender • Usually used when uploading client programs to a server E.g.: Client sending a query to a database server • Sender must be previously registered with the receiver in order to protect resources – Receiver initiated: • Initiative for code migration taken by the target machine • Receiver can be anonymous • Simpler to implement • E.g.: Java Applets

J.P. Carvalho Sistemas Distribuídos 2005/2006 26 Code and Process Migration (5)

Migration Models (cont.) • Who executes migrated code (weak mobility)? – Execute in target process • No need to start a separate process • Avoids communication at target machine • Target process needs to be protected against malicious code code execution • E.g.: Applets – Execute in a separate process • Avoids malicious code execution • Process Migration vs. Remote Cloning (strong mobility) – Clone a process instead of moving it – Cloned process runs in parallel with the original one J.P. Carvalho Sistemas Distribuídos 2005/2006 27 Code and Process Migration (6) Migration Models (cont.)

J.P. Carvalho Sistemas Distribuídos 2005/2006 28 Code and Process Migration (7)

Resource Migration • Resources migration depends on its type and often cannot simply be moved with the other segments • Process to Resource binding types: –By identifier: reference to a specific website, ftp server, local communication endpoints, etc. –By value: reference to Java libraries, C libraries, etc. –By type: a generic monitor, a generic printer, etc. • Resource to Machine binding types: – Unattached: can be easily moved between machines (e.g.: data files) – Fastened: might be moved but moving price might be costly (e.g.: local database or complete website) – Fixed: intimately bound to a specific machine or environment J.P. Carvalhoand cannot be moved Sistemas (e.g.:Distribuídos local communication 2005/2006 endpoint) 29 Code and Process Migration (8)

Resource Migration Actions • Actions to be taken with respect to the references to local resources when migrating code to another machine Resource-to-Machine binding Unattached Fastened Fixed Process-to- By identifier MV (or GR) GR (or MV) GR Resource By value CP ( or MV, GR) GR (or CP) GR binding By type RB (or GR, CP) RB (or GR, RB (or GR) CP) – GR: Establish system-wide reference – MV: Move the resources – CP: Copy the resources – RB: Rebind process to locally available resource

J.P. Carvalho Sistemas Distribuídos 2005/2006 30 Code and Process Migration (9) Migration in Heterogeneous Systems • So far it was assumed that the migrated code could easily be executed at the target system. However this assumption is only valid in homogeneous systems • On a heterogeneous environment, where operating system and machine architecture can vary, migration implies that: 1. the code segment can be executed at target platform – Solution: recompile code 2. the execution segment can be properly represented at target platform – Solution: migration stack • Execution seg. representation is the most difficult problem to be solved. Therefore weak mobility obviously simplifies the problem • Virtual machines, based on scripting languages or highly portable languages, that interpret source or automatically generated intermediate code are another obvious “recent” solution (JVM, .NET). However, this does not means that there is no need for the existence of “mobility J.P.languages” Carvalho that support Sistemas interfacesDistribuídos to existing 2005/2006 languages such as C. 31 Code and Process Migration (10) Migration in Heterogeneous Systems (cont.) • The execution segment contains not only private local data, but also platform- dependent information, like, for instance, register values. Therefore, execution segment migration is only possible (without alteration) in exactly identical machines running the same OS • Solution for procedural languages such as C is the use of a migration stack • The migration stack contains marshaled platform-independent information that is actualized whenever a subroutine (procedure, function, method, etc.) is called, or when execution returns from a subroutine. The marshaled info also contains the id of the associated subroutine. • In such systems, process migration can only occur when a subroutine is called. The migration stack is sent along with the code segment, and contains all needed information to resume execution at target machine (code must obviously be recompiled) • This approach demands that the compiler generates code to update the migration stack, and that mechanisms to return from calls are machine independent. It has been shown that slight alterations that involve the use of a preprocessor are enough to implement this approach J.P. Carvalho Sistemas Distribuídos 2005/2006 32 Code and Process Migration (11) Migration in Heterogeneous Systems (cont.) • The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment

J.P. Carvalho Sistemas Distribuídos 2005/2006 33 Code Migration Case Study: Agents Software Agents • Autonomous process capable of reacting to, and initiating changes in its environment, possibly in collaboration with other processes • More than a process: can act on its own Mobile Agent • Capability to move between machines • Support for strong mobility • E.G: D’Agents (aka Agent TCL) – Support for heterogeneous systems – Uses interpreted languages

J.P. Carvalho Sistemas Distribuídos 2005/2006 34 Code Migration Case Study: Agents(2) The architecture of the D'Agents system • Each agent executes in its own separate process

Agent code

Language independent core (implementations to agent start, stop, migration, etc.)

Agent management and authentication, management of communication between agents Interface with the network communication facilities

J.P. Carvalho Sistemas Distribuídos 2005/2006 35 Code Migration Case Study: Agents(3) Overview of Code Migration in D'Agents • A simple example of a Tcl agent in D'Agents submitting a script to a remote machine (sender initiated weak migration) proc factorial n { if ($n ≤ 1) { return 1; } # fac(1) = 1 expr $n * [ factorial [expr $n – 1] ] # fac(n) = n * fac(n – 1) } set number … # tells which factorial to compute set machine … # identify the target machine agent_submit $machine –procs factorial –vars number –script {factorial $number } agent_receive … # receive the results (left unspecified for simplicity)

J.P. Carvalho Sistemas Distribuídos 2005/2006 36 Code Migration Case Study: Agents(4) Overview of Code Migration in D'Agents (cont.) • An example of a Tcl agent in D'Agents migrating to different machines (agent_jump) where it executes the UNIX who command (strong migration) all_users $machines proc all_users machines { set list "" # Create an initially empty list foreach m $machines { # Consider all hosts in the set of given machines agent_jump $m # Jump to each host set users [exec who] # Execute the who command append list $users # Append the results to the list } return $list # Return the complete list when done } set machines … # Initialize the set of machines to jump to set this_machine # Set to the host that starts the agent # Create a migrating agent by submitting the script to this machine, from where # it will jump to all the others in $machines. agent_submit $this_machine –procs all_users -vars machines -script { all_users $machines } J.P. Carvalho Sistemas Distribuídos 2005/2006 37 agent_receive … #receive the results (left unspecified for simplicity) Code Migration Case Study: Agents(5) • The parts comprising the state of an agent in D'Agents (used to capture the state of a running agent and to send the state to other machine)

Status Description Global interpreter Variables needed by the interpreter of an variables agent Global system variables Return codes, error codes, error strings, etc. Global program variables User-defined global variables in a program Definitions of scripts to be executed by an Procedure definitions agent Stack of commands Stack of commands currently being executed Stack of activation records, one for each Stack of call frames running command

J.P. Carvalho Sistemas Distribuídos 2005/2006 38 Code Migration Case Study: Agents(6) Agent Technology • The general model of an agent platform proposed by the FIPA – Foundation for Intelligent Physical Agents

J.P. Carvalho Sistemas Distribuídos 2005/2006 39 Code Migration Case Study: Agents(7) Agent Communication Languages • Examples of different message types in the FIPA ACL, giving the purpose of a message, along with the description of the actual message content

Message Description Message Content purpose INFORM Inform that a given proposition is true Proposition QUERY-IF Query whether a given proposition is true Proposition QUERY-REF Query for a give object Expression CFP Ask for a proposal Proposal specifics PROPOSE Provide a proposal Proposal ACCEPT- Tell that a given proposal is accepted Proposal ID PROPOSAL REJECT- Tell that a given proposal is rejected Proposal ID PROPOSAL REQUEST Request that an action be performed Action specification Reference to SUBSCRIBEJ.P. CarvalhoSubscribe to Sistemas an informationDistribuídos source 2005/2006 40 source Code Migration Case Study: Agents(8) Agent Communication Languages (cont.) • A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information

Field Value

Purpose INFORM

Sender max@http://fanclub-beatrix.royalty-spotters.nl:7239

Receiver elke@iiop://royalty-watcher.uk:5623

Language Prolog

Ontology genealogy

Content female(beatrix),parent(beatrix,juliana,bernhard)

J.P. Carvalho Sistemas Distribuídos 2005/2006 41 Code Migration Case Study: ISOS ISOS – Internet Scale Operating Systems • Harness compute cycles of thousands of PCs on the internet • PCs owned by different individuals • Donate CPU cycles and storage when not in use (pool resources) • Contact coordinator for work • Coordinator: – Partition large parallel app into small tasks – Assign compute/storage tasks to PC’s • Examples: seti@home, P2P backups

J.P. Carvalho Sistemas Distribuídos 2005/2006 42 Code Migration Case Study: Condor Condor • Use idle cycles on workstations in a LAN (but also used on clusters and grids) • Used to run large batch jobs or long simulations • Idle machines contact Condor for work • Condor assigns a waiting job • When user returns to workstation, suspend job and migrate process • Flexible job scheduling policies

J.P. Carvalho Sistemas Distribuídos 2005/2006 43 Bibliography

1. Tannenbaum, A., Steen, M., “Distributed Systems: Principles and Paradigms”, Prentice- Hall International, 2002, Chapter 3. 2. Tannenbaum, A., “Modern Operating Systems”, 2nd edition, Prentice-Hall International, 2001 Other references – Processes and Threads 1. David R. Butenhof: Programming with POSIX Threads, Addison-Wesley, ISBN 0-201- 63392-2 2. Bradford Nichols, Dick Buttlar, Jacqueline Proulx Farell: Pthreads Programming, O'Reilly & Associates, ISBN 1-56592-115-1 3. Charles J. Northrup: Programming with UNIX Threads, John Wiley & Sons, ISBN 0-471- 13751-0 4. Mark Walmsley: Multi-Threaded Programming in C++, Springer, ISBN 1-85233-146-1 5. Paul Hyde: Java Thread Programming, Sams, ISBN 0-672-31585-8 6. Bill Lewis: Threads Primer: A Guide to Multithreaded Programming, Prentice Hall, ISBN 0- 1-3443698-9 7. Steve Kleiman, Devang Shah, Bart Smaalders: Programming With Threads, SunSoft Press, ISBN 0-13-172389-8 8. Pat Villani: Advanced WIN32 Programming: Files, Threads, and Process Synchronization, Harpercollins Publishers, ISBN 0-87930-563-0 9. Jim Beveridge, Robert Wiener: Multithreading Applications in Win32, Addison-Wesley, ISBN 0-201-44234-5 10. Thuan Q. Pham, Pankaj K. Garg: Multithreaded Programming with Windows NT, Prentice Hall, ISBN 0-131-20643-5

J.P. Carvalho Sistemas Distribuídos 2005/2006 44 Bibliography (2)

11. Len Dorfman, Marc J. Neuberger: Effective Multithreading in OS/2, McGraw-Hill Osborne Media, ISBN 0070178410 12. Uresh Vahalia: Unix Internals: the New Frontiers, Prentice Hall, ISBN 0-13-101908-2 13. Alan L. Dennis: .Net Multithreading , Manning Publications Company, ISBN 1-930-11054-5 14. Tobin Titus, Fabio Claudio Ferracchiati, Srinivasa Sivakumar, Tejaswi Redkar, Sandra Gopikrishna: C# Threading Handbook, Peer Information Inc, ISBN 1-861-00829-5 15. Tobin Titus, Fabio Claudio Ferracchiati, Srinivasa Sivakumar, Tejaswi Redkar, Sandra Gopikrishna: Visual Basic .Net Threading Handbook, Wrox Press Inc, ISBN 1-861-00713-2 – Process Migration in Distributed Computing 1. F. Douglis and J. Ousterhout, "Process Migration in the Sprite Operating System:A Status Report" 2. M.Theimer, K.Lantz, D.Cheriton, ''Preemptable Remote Execution'', Proceedings of the 10th SOSP, Operating Systems Review, Vol. 19, No. 5, Pages 2-12, December 1985 3. R. Gray, “Agent TCL: Alpha Release 1.1”, Technical Report, Dartmouth College, Hannover, NH, 1995 4. The Worldwide Computer. An operating system spanning the Internet would harness the power of millions of the world's networked PCs. Scientific American, February 2002 5. Condor: A Hunter of Idle Workstations, Proc of IEEE ICDCS 1988. 6. Jim Basney and Miron Livny, "Deploying a High Throughput Computing Cluster", High Performance Cluster Computing, Rajkumar Buyya, Editor, Vol. 1, Chapter 5, Prentice Hall PTR, May 1999. More information about Condor is available at its homepage http://www.cs.wisc.edu/condor/

J.P. Carvalho Sistemas Distribuídos 2005/2006 45 Bibliography (3)

WWW links – Real World Tech article by Paul DeMone - Explaining different types of multithreading, hardware implementation requirements and the impact on software. – Ars Technica article about multithreading, etc – Page 1 & Page 2, a preemptive multithreaded implementation described – Forum – Answers to frequently asked questions for comp.programming.threads – Frequently Asked Questions, Most FAQ – Discussion "Writing a scalable server" – The C10K problem – Business logic processing in a socket server - thread pools – System support for scalable network servers – Article "Multi-threading basics" by Giancarlo Niccolai – Article "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" by Herb Sutter – An Implementation of Scheduler Activations on the NetBSD Operating System – DragonFly - Light Weight Kernel Threading Model – Java(TM) and Solaris(TM) Threading – Java Tech Talk All about Java Technology. Every thing between try {} catch.

J.P. Carvalho Sistemas Distribuídos 2005/2006 46