Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Erlang Solutions Ltd.
© 1999-2014 Erlang Solutions Ltd.
Wherefore art thou Erlang?
Robert Virding !
Principal Language Expert Erlang Solutions Ltd.
© 1999-2014 Erlang Solutions Ltd.
Concurrency vs parallelism
���2
© 1999-2014 Erlang Solutions Ltd.
Overview
• A bit of history • A bit of philosophy • A few examples • Brave new world • A pat on the back
���3
© 1999-2014 Erlang Solutions Ltd.
The problem
• Ericsson has a “best seller” product (the AXE telephone exchanges)
• The product is very successful, but costly and difficult to maintain
���4
© 1999-2014 Erlang Solutions Ltd.
The problem
• How to simplify the developing and maintenance processes?
���5
© 1999-2014 Erlang Solutions Ltd.
Problem domain• Actions must be performed at a certain point in time or within a certain
time. • System may be distributed over several computers. • The system is used to control hardware. • The software system is very large. • The system exhibits complex functionality such as feature interaction. • The systems should be in continuous operation over many years. • Software maintenance (reconfiguration etc.) should be performed without
stopping the system. • There are stringent quality, and reliability requirements. • Fault tolerance both to hardware failures, and software errors, must be
provided. • The system must be able to handle very large numbers of concurrent
activities. Bjarne Däcker, November 2000 - Licentiate Thesis
���6
© 1999-2014 Erlang Solutions Ltd.
Hard at work developing Erlang
���7
© 1999-2014 Erlang Solutions Ltd.
Overview
• A bit of history • A bit of philosophy • A few examples • Brave new world • A pat on the back
���8
© 1999-2014 Erlang Solutions Ltd.
Some reflections
We were NOT trying to implement a functional language
We were NOT trying to implement the actor model !
���9
WE WERE TRYING TO SOLVE THE PROBLEM!
© 1999-2014 Erlang Solutions Ltd.
Basic principles/requirements
• Lightweight, massive concurrency - Asynchronous communication
• Process isolation • Fault tolerance • Continuous evolution of the system
- Dynamic code updating
• Distribution • Soft real-time
���10
© 1999-2014 Erlang Solutions Ltd.
Secondary principles/requirements
• "Safe" language • Simple high-level language
- Simple in the sense that there should be a small number of basic principles, if these are right then the language will be powerful but easy to comprehend and use. Small is good.
• Provide tools for building systems, not solutions - Too limited - (and we usually got them wrong)
���11
© 1999-2014 Erlang Solutions Ltd.
Overview
• A bit of history • A bit of philosophy • A few examples • Brave new world • A pat on the back
���12
© 1999-2014 Erlang Solutions Ltd.
!
!
How Erlang does it
���13
© 1999-2014 Erlang Solutions Ltd.
Sequential Language
• Simple functional language - With a “different” syntax
• It is safe! - For example no pointer errors
• It is reasonably high-level - At least then it was - Still is in many ways
• Dynamically typed! • No user defined data-types!
���14
© 1999-2014 Erlang Solutions Ltd.
Sequential Language
• Typical features of functional languages - Immutable data - Immutable variables - Extensive use of pattern matching - Recursion rules!
���15
© 1999-2014 Erlang Solutions Ltd.
!inc_list([H|T]) -> [H+1|inc_list(T)]; inc_list([]) -> []. !member(X, [X|T]) -> true; member(X, [_|T]) -> member(X, T); member(_, []) -> false.
Sequential Language
• Using recursion to process lists
���16
© 1999-2014 Erlang Solutions Ltd.
!<<?IP_VERSION:4, HLen:4, SrvcType:8, TotLen:16, ID:16, Flgs:3, FragOff:13, TTL:8, Proto:8, HdrChkSum:16, SrcIP:32, DestIP:32, RestDgram/binary>>
High-level binaries
• IP datagram of IP protocol version 4
���17
© 1999-2014 Erlang Solutions Ltd.
Concurrency
• Light-weight “green” processes - Millions of Erlang processes possible on one
machine - and running in a product
• Processes are used for everything - Concurrency - Managing state
• Processes are isolated! • No global data!
���18
© 1999-2014 Erlang Solutions Ltd.
Concurrency: spawning processes• Before
- Code executed by Process 1 - process identifier is Pid1 - Pid2 = spawn(M, F, A)
• After - A new process with Pid2 is
created - Pid2 is only known to Pid1 - Pid2 runs M:F(A) - M:F/Arity must be exported
• Convention: we identify processes by their process ids (pids)
���19
Pid2 = spawn(Mod, Func, Args)
Mod:Func(Arg1, ...)
Pid2
Pid1
© 1999-2014 Erlang Solutions Ltd.
Concurrency: message passing• Messages are sent using
the Pid ! Msg expression
• Received messages are stored in the process’s mailbox
• Messages are received using the receive ... end expression
• Messages can be matched and selectively retrieved
• Mailboxes are scanned sequentially.
���20
Pid2Pid1
Pid2 ! {self(),foo}
{Pid1,foo}
receive start -> ... stop -> ... {Pid, foo} -> ... end
!!! {Pid, foo} -> ...
© 1999-2014 Erlang Solutions Ltd.
ringing_a_side(Addr, B_Pid, B_Addr) -> receive on_hook -> B_Pid ! cleared, tele_os:stop_tone(Addr), idle(Addr); answered -> tele_os:stop_tone(Addr), tele_os:connect(Addr, B_Addr), speech(Addr, B_Pid, B_Addr); {seize,Pid} -> Pid ! rejected, ringing_a_side(Addr, B_Pid, B_Addr); _ -> ringing_a_side(Addr, B_Pid, B_Addr) end.
Code exampleringing_b_side(Addr, A_Pid) -> receive cleared -> tele_os:stop_ring(Addr), idle(Addr); off_hook -> tele_os:stop_ring(Addr), A_Pid ! answered, speech(Addr, A_Pid, not_used); {seize,Pid} -> Pid ! rejected, ringing_b_side(Addr, A_Pid); _ -> ringing_b_side(Addr, A_Pid) end.
���21
© 1999-2014 Erlang Solutions Ltd.
Error handling
!
!
ERRORS WILL ALWAYS OCCUR!
���22
© 1999-2014 Erlang Solutions Ltd.
Error handling
!
!
The system must never go down!
!
Parts may crash and burn BUT
The system must never go down!���23
© 1999-2014 Erlang Solutions Ltd.
Error handling
System must be able to - Detect - Contain - Handle - Recover from
errors
���24
© 1999-2014 Erlang Solutions Ltd.
Error handling• Links between processes
• Exit Signals are sent along links when processes terminate abnormally
• The process receiving the signal will exit
• Then propagate a new signal to the processes to which it is linked
���25
PidA PidB
© 1999-2014 Erlang Solutions Ltd.
Error handling• Processes can trap exit
signals.
• Exit signals will be converted to messages
• They are saved in the process mailbox
• If an exit signal is trapped, it does not propagate further
���26
PidA PidB
© 1999-2014 Erlang Solutions Ltd.
Robust systems
How do you build robust systems? !
• You need to ensure - Necessary functionality always available - System cleans up when things go wrong
• Must have at least two machines! - Need distribution
���27
© 1999-2014 Erlang Solutions Ltd.
Robust systems: Supervision trees
• Supervisors will start child processes - Workers - Supervisors
• Supervisors will monitor their children - Through links and trapping exits
• Supervisors can restart the children when they terminate
���28
Supervisors
Workers
© 1999-2014 Erlang Solutions Ltd.
Robust systems: Monitor processes
• Servers monitoring clients - Clean-up after then if they crash
• Processes monitoring co-workers • Groups of co-workers dying together
���29
© 1999-2014 Erlang Solutions Ltd.
Code handling
• Module is the unit of all code handling - No inter-module dependencies
- Causes problems with static typing
• Have two versions of each module - Old and current - Allows controlled take-over
• Well defined behaviour with respect to code - You KNOW what happens when you call a function - You KNOW what happens when you load a module
���30
© 1999-2014 Erlang Solutions Ltd.
OTP (Open Telecom Platform)
���31
Applications & Libraries
System Design Principles
© 1999-2014 Erlang Solutions Ltd.
OTP: Design Patterns
• Processes share similar structures and life cycles - They are started - They receive messages and send replies - They are terminated (or crash)
• Even if they perform different tasks, they will perform them following a set of patterns
• Each design pattern solves a specific problem • OTP Behaviours are a formalisation of design
patterns
���32
© 1999-2014 Erlang Solutions Ltd.
OTP: Behaviours
• The idea is to split the code in two parts
• The generic part is called the generic behaviour - They are provided by OTP as library modules
• The specific part is called the callback module - They are implemented by the programmer
���33
specific callback module
generic behaviour module
Server
process
© 1999-2014 Erlang Solutions Ltd.
OTP: Behaviours
Generic Servers Used to model client-server behaviours
Generic Finite-State Machines Used for finite-state machine programming
Generic Event Handler/Manager Used for writing event handlers
Supervisors Used for fault-tolerant supervision trees
Application Used to encapsulate resources and functionality
���34
© 1999-2014 Erlang Solutions Ltd.
Overview
• A bit of history • A bit of philosophy • A few examples • Brave new world • A pat on the back
���35
© 1999-2014 Erlang Solutions Ltd.
Problem domain• Actions must be performed at a certain point in time or within a certain
time. • System may be distributed over several computers. • The system is used to control hardware. • The software system is very large. • The system exhibits complex functionality such as feature interaction. • The systems should be in continuous operation over many years. • Software maintenance (reconfiguration etc.) should be performed without
stopping the system. • There are stringent quality, and reliability requirements. • Fault tolerance both to hardware failures, and software errors, must be
provided. • The system must be able to handle very large numbers of concurrent
activities. Bjarne Däcker, November 2000 - Licentiate Thesis
���36
Not Just Telecom
© 1999-2014 Erlang Solutions Ltd.
!
!
The Erlang concurrency model scales!
���37
© 1999-2014 Erlang Solutions Ltd.
The Erlang SMP goal
!
SMP should be transparent to the programmer! !
You shouldn’t have to think about it (though sometimes you may want to)
���38
© 1999-2014 Erlang Solutions Ltd.
The Erlang SMP goal
!
The BEAM does this using Schedulers !
• The running BEAM consists of a number of schedulers
���39
Scheduler #1 Scheduler #2 Scheduler #3 Scheduler #N...
Erlang VM
© 1999-2014 Erlang Solutions Ltd.
Schedulers
• Semi-autonomous BEAM VM • One per VM thread
- By default one VM thread per core
• Contains its own run-queue - Run-queue contains things to be done
• Run as separately as possible - Reduce nasties like locks/synchronisation
- Does its own memory management
���40
© 1999-2014 Erlang Solutions Ltd.
Schedulers: balancing
• Once every period (20-40k reductions) a new master scheduler is chosen - Basically first to reach that count
• Master balances/optimises workloads on schedulers
• Schedules changes on other schedulers run-queues
���41
© 1999-2014 Erlang Solutions Ltd.
Schedulers: scheduling processes
• Each scheduler has its own run-queue • Processes suspend when waiting for messages
- Not a busy wait
• Suspended processes become runnable when a message arrives - Put on the run-queue
• Running processes will be - Suspended waiting for a message - Re-scheduled after 2000 reductions
���42
© 1999-2014 Erlang Solutions Ltd.
Process Memory
• Each process has a separate heap • All process data local to process
!
• Sending messages means copying data !
• This NOT required by Erlang which just specifies process isolation
���43
© 1999-2014 Erlang Solutions Ltd.
Isn’t all this data copying terribly inefficient?
���44
Well, yes. Sort of. Maybe.
BUT ...
© 1999-2014 Erlang Solutions Ltd.
Process Memory
Having separate process heaps has some important benefits • Allows us to collect each process separately • Needs no synchronisation
- This is a BIG WIN™ - And it gets bigger the more cores you have!
• Garbage collection becomes more efficient • Garbage collector becomes simpler • Cache coherency and NUMA!
���45
© 1999-2014 Erlang Solutions Ltd.
Erlang is NOT good for everything !
BUT !
It IS very good at interfacing other “things”
!
Many/most applications use Erlang together with other languages systems
���46
© 1999-2014 Erlang Solutions Ltd.
Overview
• A bit of history • A bit of philosophy • A few examples • Brave new world • A pat on the back
���47
© 1999-2014 Erlang Solutions Ltd.
Who is using Erlang?
���48
© 1999-2014 Erlang Solutions Ltd.
Erlang based tools• CouchDB
- Distributed, robust document database
• Riak - Distributed, partition tolerant
scalable database
• RabbitMQ - High performance enterprise
AMQP messaging
• Ejabberd - XMPP instant messaging
server
���49