2014-04-03 budapest wherefore art thou erlang · © 1999-2014 erlang solutions ltd. overview • a...

Erlang Solutions Ltd.

© 1999-2014 Erlang Solutions Ltd.

Wherefore art thou Erlang?

Robert Virding !

Principal Language Expert Erlang Solutions Ltd.


Concurrency vs parallelism

��2


Overview

• A bit of history • A bit of philosophy • A few examples • Brave new world • A pat on the back

��3


The problem

• Ericsson has a “best seller” product (the AXE telephone exchanges)

• The product is very successful, but costly and difficult to maintain

��4


The problem

• How to simplify the developing and maintenance processes?

��5


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


Hard at work developing Erlang

��7


Overview


��8


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!


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


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


Overview


��12


!

!

How Erlang does it

��13


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


Sequential Language

• Typical features of functional languages - Immutable data - Immutable variables - Extensive use of pattern matching - Recursion rules!

��15


!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


!<<?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


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


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


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} -> ...


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


Error handling

!

!

ERRORS WILL ALWAYS OCCUR!

��22


Error handling

!

!

The system must never go down!

!

Parts may crash and burn BUT

The system must never go down!��23


Error handling

System must be able to - Detect - Contain - Handle - Recover from

errors

��24


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


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


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


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


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


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


OTP (Open Telecom Platform)

��31

Applications & Libraries

System Design Principles


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


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


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


Overview


��35


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


!

!

The Erlang concurrency model scales!

��37


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


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


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


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


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


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


Isn’t all this data copying terribly inefficient?

��44

Well, yes. Sort of. Maybe.

BUT ...


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


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


Overview


��47


Who is using Erlang?

��48


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


!

Thank you! Questions? !

!

[email protected] @rvirding

��50

mailto:[email protected]

2014-04-03 budapest wherefore art thou erlang · © 1999-2014 erlang solutions ltd. overview • a...

Documents