LINF 2345 Processes

1
LINF 2345Processes

• Seif Haridi
• Peter Van Roy

2
Processes

• Threads and processes
• Threads in distributed systems
• Code migration
• Software agents

3
Threads and Processes
4
Basic Concepts (1)

• Processor An active entity that understands a
  set of instructions, that is, it is able to
  execute these instructions
• Processors can be hardware (physical) or software
  (virtual)
• Virtual processor A processor built in software,
  on top of one or more physical processors
• The operating system creates virtual processors,
  each called a process (often defined as a
  program in execution)
• Great care is taken to ensure that these virtual
  processors cannot maliciously or inadvertently
  affect the correctness of each others behavior
  (concurrency transparency)
• Process context The state needed to specify a
  process execution. It is voluminous address
  translation, resources in use, accounting
  information.

5
Basic Concepts (2)

• Thread A minimal software processor in whose
  context a series of instructions can be executed
• No effort is taken to isolate threads from each
  other they share data and resources directly
• Threads implement partial order of instruction
  execution, nothing more
• Thread context A small amount of state, usually
  CPU state (registers, pointer to thread stack)
  with some extra state (currently blocked on mutex
  variable, for example)
• Performance of a multithreaded application is not
  worse than its single-threaded counterpart

6
Basic Concepts (3)

• Competitive concurrency
• Execution of processes in the context of a
  physical processor. Each process has its own
  goals to achieve and they compete for system
  resources. Usually they execute independently
  written programs.
• Cooperative concurrency
• Execution of threads in the context of a process.
  Threads are designed to work together to achieve
  a common goal. Usually they are execute within a
  single program.

7
Context Switching

• The act of changing which concurrent entity
  (process/thread) is currently executing
• Process context
• The information needed to specify the execution
  of a process. Assumes that the processor does
  not change.
• Thread context
• The information needed to specify the execution
  of a thread. Assumes that the process does not
  change.

8
Context Switching

• Observation 1
• Threads share the same address space. Thread
  context switching can be done entirely
  independent of the operating system.
• Observation 2
• Process switching is generally more expensive as
  it involves getting the OS in the loop, i.e.,
  trapping to the kernel
• Observation 3
• Creating and destroying threads is much cheaper
  than doing so for processes.

9
Threads andOperating Systems

• Main issue Should an OS kernel provide threads,
  or should they be implemented as user-level
  packages?

10
User Space Solution

• Well have nothing to do with the kernel, so all
  operations can be completely handled within a
  single process
• Implementations can be extremely efficient
• Observation All services provided by the kernel
  are done on behalf of the process in which a
  thread resides
• If the kernel decides to block a thread, the
  entire process will be blocked
• Conclusion All I/O and external events should be
  non-blocking

11
User Space Solution

• Threads are used when there are lots of external
  events
• Threads block on a per-event basis
• The process never blocks
• If the kernel cant distinguish threads, how can
  it support signaling events to them?
• Solution Central routine
• Event requests are indexed by threads
• Checks regularly for new external events
• Moves threads from blocking to running and
  vice-versa

12
Kernel Space Solution

• The whole idea is to have the kernel contain the
  implementation of a thread package. This means
  that all operations return as system calls.

13
Kernel Space Solution

• Operations that block a thread are no longer a
  problem the kernel schedules another available
  thread within the same process
• Handling external events is simple the kernel
  (which catches all events) schedules the thread
  associated with the event
• If there are multiple physical processors,
  performance can be increased by mapping threads
  to different processors
• One problem is the loss of efficiency due to the
  fact that each thread operation requires a trap
  to the kernel
• Another problem is loss of portability an
  implementation is limited to a single operating
  system, porting to another is difficult

14
Threads and OS

• Many systems mix user-level and kernel-level
  threads
• Lightweight process (LWP) several per
  (heavy-weight) process, supported by kernel
• Complemented by user-level thread package
• Others, like Mozart/Oz and Erlang, do not
• www.mozart-oz.org
• www.erlang.org
• Supports only user-level threads
• Gives portability and efficiency

15
Solaris Threads

• Basic idea Introduce a two-level threading
  approach lightweight processes (LWP) that can
  execute user-level threads

16
Solaris Threads
17
Solaris Threads

• When a user-level thread does a system call, the
  LWP that is executing that thread blocks. The
  thread remains bound to the LWP.
• The kernel can simply schedule another LWP having
  a runnable thread bound to it. Note that this
  thread can switch to any other runnable thread
  currently in user space.

18
Solaris Threads

• When a thread calls a blocking user-level
  operation, we can simply do a context switch to a
  runnable thread, which is then bound to the same
  LWP (user-level context switch)
• When there are no threads to schedule, an LWP may
  remain idle, and may even be removed (destroyed)
  by the kernel

19
Threads inDistributed Systems
20
Threads inDistributed Systems

• Lets take a look at threads in the context of a
  common distributed programming idiom, namely the
  client/server
• Multithreaded clients and servers
• Other aspects of clients and servers
• Later on in the course, when we look at
  transparent distribution, we will see other ways
  to use threads
• Dataflow execution
• Decentralized (peer-to-peer) execution

21
Multithreaded Clients

• Main issue is hiding network latency

22
Multithreaded Clients

• Main issue is hiding network latency
• Multithreaded Web client
• Web browser scans an incoming HTML page, and
  finds that more files need to be fetched
• Each file is fetched by a separate thread, each
  doing a (blocking) HTTP request
• As files come in, the browser displays them

23
Multithreaded Clients

• Main issue is hiding network latency
• Multiple RPCs/RMIs
• A client does several RPCs at the same time, each
  one by a different thread
• It then waits until all results have been
  returned
• Note if RPCs are to different servers, we may
  have a linear speed-up compared to doing RPCs one
  after the other

24
Multithreaded Servers

• Main issue is improved performance and better
  program structure

25
Improved Performance in Servers

• Starting a thread to handle an incoming request
  is much cheaper than starting a new process
• Having a single-threaded server prohibits simply
  scaling the server to a multiprocessor system
• As with clients hide network latency by reacting
  to next request while previous one is being
  replied

26
Better Program Structure in Servers

• Most servers have high I/O demands. Using simple,
  well-understood blocking kernel calls simplifies
  the overall structure.
• Multithreaded programs tend to be smaller and
  easier to understand due to simplified flow of
  control as it reflects the structure on the
  (concurrent) model

27
Clients

• User interfaces
• Other client-side software

28
User interfaces
Essence A major part of client-side software is
focused on (graphical) user interfaces X kernel
and X application may be on different machines
29
User interfaces

• Compound documents Make the user interface
  application-aware to allow inter-application
  communication
• drag-and-drop move objects to other positions on
  the screen, possibly invoking interaction with
  other applications
• in-place editing integrate several applications
  at user-interface level (word processing
  drawing facilities)
• Illusion of single desktop, with network
  operations underneath
• User interface transparency
• This is one way to hide network operations we
  will see many more!

30
Client-Side Software

• Essence Often focused on providing distribution
  transparency

31
Client-Side Software

• Essence Often focused on providing distribution
  transparency
• access transparency
• client-side stubs for RPCs and RMIs
• location/migration transparency
• let client-side software keep track of actual
  location

32
Client-Side Software

• Essence Often focused on providing distribution
  transparency
• replication transparency multiple invocations
  handled by client stub
• failure transparency can often be placed only at
  client (were trying to mask server and
  communication failures)

33
Servers

• General server organization
• Object servers

34
General Organization Basic model

• A server is a process that waits for incoming
  service requests at a specific transport address
• In practice, there is a one-to-one mapping
  between a port and a service

35
General Organization Basic model

• In practice, there is a one-to-one mapping
  between a port and a service

36
Super Servers

• Servers that listen to several ports, i.e.,
  provide several independent services.
• In practice, when a service request comes in,
  they start a process to handle the request

37
Iterative vs. concurrent servers

• Iterative servers can handle only one client at a
  time, in contrast to concurrent servers
• Iterative servers are sequential programs
• Concurrent servers use multiple threads
• New thread for each request (multithreaded)
• New process for each request (typical Unix style)

38
Out-of-Band Communication

• Issue Is it possible to interrupt a server once
  it has accepted (or is in the process of
  accepting) a service request?

39
Out-of-Band CommunicationSolution 1

• Issue Is it possible to interrupt a server once
  it has accepted (or is in the process of
  accepting) a service request?
• Use a separate port for urgent data (possibly per
  service request)
• Server has a separate thread (or process) waiting
  for incoming urgent messages
• When an urgent message comes in, the associated
  service request is put on hold
• Note we require OS to support high-priority
  scheduling of specific threads or processes

40
Out-of-Band CommunicationSolution 2

• Issue Is it possible to interrupt a server once
  it has accepted (or is in the process of
  accepting) a service request?
• Use out-of-band communication facilities of the
  transport layer
• Example TCP allows to send urgent messages in
  the same connection
• Urgent messages can be caught using OS signaling
  techniques

41
Servers and StateStateless Servers

• Never keep accurate information about the status
  of a client after having handled a request
• Dont record whether a file has been opened
  (simply close it again after access)
• Dont promise to invalidate a clients cache
• Dont keep track of your clients

42
Servers and StateStateless Servers Consequences

• Clients and servers are completely independent
• State inconsistencies due to client or server
  crashes are reduced
• Possible loss of performance because, e.g., a
  server cannot anticipate client behavior (think
  of prefetching file blocks)

43
Servers and StateStateless Servers Consequences

• Clients and servers are completely independent
• State inconsistencies due to client or server
  crashes are reduced
• Possible loss of performance because, e.g., a
  server cannot anticipate client behavior (think
  of prefetching file blocks)
• Question Does connection-oriented communication
  fit into a stateless design?

44
Servers and StateStateful Servers

• Stateful servers keep track of the status of
  clients
• Record that a file has been opened, so that
  prefetching can be done
• Know which data a client has cached, and allow
  clients to keep local copies of shared data
• For Web server, server state stored at client
  (cookie) gets the effect of a stateful server
  while keeping the server stateless
• Observation The performance of stateful servers
  can be extremely high, provided clients are
  allowed to keep local copies. As it turns out,
  reliability is not a major problem.

45
Object Servers

• A server tailored to support distributed objects
• Some concepts servant, skeleton, object adapter
• Servant The actual implementation of an object,
  sometimes containing only method implementations
• Java or C classes
• Doesnt need to be in an OO language
• Collection of C or COBOL functions, that act on
  structs, records, database tables, etc.

46
Object Servers

• Skeleton Server-side stub for handling network
  I/O
• Unmarshalls incoming requests, and calls the
  appropriate servant code
• Marshalls results and sends reply message
• Generated from interface specifications

47
Object Servers

• Object adapter The manager of a set of objects
• Inspects (as first) incoming requests
• Ensures referenced object is activated (requires
  identification of servant)
• Passes request to appropriate skeleton, following
  specific activation policy
• Responsible for generating object references

48
Object Servers

• Observation Object servers determine how their
  objects are constructed

49
Code Migration
50
Code Migration

• Approaches to code migration
• Migration and local resources
• Migration in heterogeneous systems

51
Code Migration Some Context
CS Client-ServerREV Remote Evaluation
52
Code Migration Some Context
CoD Code on DemandMA Mobile Agent
53
Strong and Weak Mobility

• Object/thread/agent components
• Code segment contains the actual code
• Data segment contains the state
• Execution state contains context of thread
  executing the objects code (e.g. execution
  stack)

54
Weak Mobility

• Move only code and data segment (and start
  execution from the beginning) after migration
• Relatively simple, especially if code is portable
• Distinguish code and data-segment shipping (push)
  from code and data-segment fetching (pull)

55
Strong Mobility

• Move whole component, including execution state
• Migration versus cloning
• Migration move the entire object/thread from one
  machine to the other
• Cloning start a copy of the original
  object/thread and set it in the same execution
  state

56
Managing Local Resources

• Problem An object uses local resources that may
  or may not be available at the target site
• Resource types
• Fixed the resource cannot be migrated, such as
  local hardware, file descriptors
• Fastened the resource can, in principle, be
  migrated but only at high cost (files or file
  systems)
• Unattached the resource can easily be moved
  along with the object (e.g. a cache, local
  application-specific objects)

57
Managing Local Resources

• Problem An object uses local resources that may
  or may not be available at the target site
• Object-to-resource binding
• By identifier/reference the object requires a
  specific instance of a resource (e.g. a specific
  database)
• By value the object requires the value of a
  resource (e.g. the set of cache entries)
• By type the object requires that only a type of
  resource is available (e.g. a color monitor)

58
Protocols for ManagingLocal Resources
59
Other Distribution Protocolsfor Local Resources

• The four protocols mentioned (GR, MV, CP, and RB)
  are special cases of more general protocols
• GR and MV are protocols for stateful entities
• CP is a protocol for stateless entities
• RB is a protocol for an entity that may be
  stateful but whose state does not need to be
  transferred
• Other protocols are possible for stateful and
  stateless entities
• Invalidation protocol for stateful entities
• Immediate copy / copy if not local / lazy copy
  for stateless entities
• Other kinds of entities are possible (single
  assignment or dataflow) with new protocols
  (lazy/eager, demand-driven or supply-driven)
• We will see some of these later in the course!

60
Migration in HeterogeneousSystems

• Main problems
• The target machine may not be suitable to execute
  the migrated code
• The definition of process/thread/processor
  context is highly dependent on local hardware,
  operating system, and runtime system

61
Migration in HeterogeneousSystems

• Main problems
• The target machine may not be suitable to execute
  the migrated code
• The definition of process/thread/processor
  context is highly dependent on local hardware,
  operating system, and runtime system
• Solution Make use of an abstract machine that is
  implemented on different platforms

62
Migration in HeterogeneousSystems

• Main problems
• The target machine may not be suitable to execute
  the migrated code
• The definition of process/thread/processor
  context is highly dependent on local hardware,
  operating system, and runtime system
• Current solutions
• Interpreted languages running on a virtual
  machine (Java/JVM Mozart virtual machine)
• Existing languages (C or Java) allow migration
  at specific transferable points, such as just
  before a function call (weak mobility)

63
Mobility of Code and Agents

• Study DAgents
• Weak mobility initiated by sender
• Strong mobility by process migration/cloning
• Study Mozart
• Later in the course we will study all aspects
  touched upon in this lecture

64
Software Agents
65
Software Agents

• Whats an agent?
• Agent technology

66
Whats an Agent?

• An autonomous process capable of reacting to and
  initiating changes in its environment, possibly
  in collaboration with users and other agents
• collaborative agent collaborate with others in a
  multi-agent system
• mobile agent can move between machines
• interface agent assist users at user-interface
  level
• information agent manage information from
  physically different sources
• There is another definition in the artificial
  intelligence community
• See the book Artificial Intelligence A Modern
  Approach
• Bounded rationality (reasoning with limited
  resources)

67
Whats an Agent?
68
Agent Technology
The general model of an agent platform (adapted
from FIPA, fipa98-mgt)
69
Agent Technology

• Management Keeps track of where the agents on
  this platform are (mapping agent ID to port)
  (white pages)
• Directory Mapping of agent names/services
  attributes to agent IDs (Yellow pages)
• ACC Agent Communication Channel, used to
  communicate with other platforms

70
Agent Communication Language

• Agent Communication Language ACL is application
  level protocol, making distinction between
  purpose and content of a message

71
Agent Communication Language
72
Agent Communication Language

• A simple example of a FIPA ACL message sent
  between two agents using Prolog to express
  genealogy information