today i wanted to talk about a
property of functional programming
called immutability
and how immutability helps affect
concurrency models
and you know the advantages and
disadvantages of having immutable states
you know so they should be used
in some areas and not used in others
if you remember when you were back in
school they used to go in and
teach you the equations say y
is equal to x squared minus 1. you did
your calculation and then you figured
out what y was
and
that worked fine until they started
teaching you to program all of a sudden
when they were teaching you to program
what you got was x is equal to x squared
minus one and all of a sudden they
introduced mutability into the whole
equation where you had values but then
you went in and changed the values this
started causing kind of confusion and
because it's wrong it kind of defies the
laws of mathematics this is wrong you
know it shouldn't be that way even when
you program you should have you know y
is equal to x squared minus one and this
is an example of an immutable state so
mutability that's the idea of something
can change right so x is something and
then it can become something else that
is correct so uh mutability what you do
is uh you change some parts of it
and you retain some common bits so you
know that's mutability you you basically
the value changes
or some parts of that value change
immutability basically you share
what you can and copy what you can't
that's a way of seeing it let's look at
how immutability and mutability affect
your concurrency models concurrently
programming is when you have processes
as your main building block of your
system
and concurrence itself you know what you
do is you they don't have to run at the
same time but you model it that way so
they could inferiorly be running at the
same time and it's an easier way to
reason and an easier way to code and
program
and and this goes
in contrast to parallelism where you
actually have processes which are
running at the same time so
see it as a subset you know cc
concurrency as a subset of parallelism
so there are two ways of you know doing
concurrency one is based on mutable
state
where we've got
processes and processes usually threads
when it comes to mutable state will go
in and share memory so that means
any thread you know which has access to
the shared memory can go in and edit it
and this is where you program with locks
you program with semaphores
and the likes then you've got notion
memory so you've got
concurrency models with immutable state
and in those cases you've got processes
and processes do not share memory but
they communicate with each other through
message passing so they communicate with
each other by copying
the data from one process to the other
and so now they'll each have their own
copy
and you know they're able to do whatever
they want with it so you know the only
entity the only item which is allowed to
mutate the process state is the process
itself if we're dealing with a mutable
state
um
you've got a thread or a process running
in a critical section so basically
writing to the shared memory what
happens if something goes wrong so what
happens if the process terminates what
you need to do is you need to go and
terminate all of the threads which have
access to the shared memory because you
do not know you know what state the
process which terminated left the shared
memory in and it could you know
potentially be corrupt so you basically
lose everything
in there in a mutable state
what happens if a process
you know state gets corrupted or crashes
or something goes wrong with it is that
you just lose the state of that
particular process which was corrupt in
the first place
all other processes are not affected by
it because they'll have their own copy
of the data hopefully not corrupted and
you know continue executing so it's a
way of isolating failure your second
problem with mutable state is you know
where do you locate your data you've got
shared memory where do you locate it so
you've got a process
running in nottingham and you've got one
process running in london
and they need to share memory where you
place your shared memory it becomes a
bit hard versus immutable state where
you've got nottingham and you've got
london you don't share memory you copy
the state so they'll each have their own
copy of the data
and you can execute yeah without so so
so you you're avoiding problems of
locality here assume you figure out with
your mutable state between nottingham
and london you'll place your shared
memory in leicester what happens all of
a sudden when the network goes down
between them you know because here in
the middle you've got your shared data
all of a sudden you can't accept it and
there's one thing you need to be aware
when you're programming in life there
are three certainties one is taxes death
and network partitions so
you can be sure that
you know if you've got a network
something will go wrong with it versus
immutable state you've got a copy
nottingham you've got a copy in london
so even if the network goes down
they'll each have their own copy of the
data to continue running
and what you need to do is when the
network does come back up you will have
to go in and synchronize the data again
and there are many tools
distributed databases and techniques to
do that it's very clear that if you're
dealing with mutable state the
mutability will work but it will work
only if you're running your threads on a
single machine so without a network and
assuming nothing goes wrong and there
are many many use cases where you need
that approach especially those use cases
where copying memory
is not efficient you know where your
computations have been extremely fast
so it's not a question of you know one
or the other it's a question very much
of using
the right tool for the job and yeah it's
not always mutable state and it's not
always a mutable state you know these
these are the science decisions you need
to make when you go along there's some
examples of where you might choose a
mutable state most likely i mean you
would use a mutable state where say in
the finance space where you're doing
algorithmic trading
computation time is critical
and complex as well
where
if something crashes and go wrong you
just don't do the trade
but if you do get your results you know
you need to be fast and you
you know get you know execute that trade
as quickly as possible so as as an
example or
your rendering of graphics for example
or
you know where you might want to split
it up but uh you know
do do as much as you want as much as
possible in parallel so it's time
critical basically time critical
applications absolutely which can run on
a single machine and don't need to be
distributed so let's step back a second
uh you know i've been using the terms
mutable state and immutable state
you probably recognize them with the no
shared memory
approach versus the shared memory
approach
and i think a very common shared memory
approach is for for example java which
is fred's and the threads will go in and
share the memory
and what i'm seeing happening a lot out
there though is applying uh techniques
from immutable state
to processes and threads with mutable
state so what happens is that you you
only allow
the thread you know which owns the data
to go in and mutate it
and yeah and that resolves and addresses
a lot of the issues you know we've
discussed now so you know
it's again you're very much the right
tool for the job so if you look at
modern architectures today i mean
everything from embedded devices to
super computers
they are based on you know heterogeneous
multi-core architectures
and most of them are you know by nature
distributed so you know i think you know
what we've been looking at today
is basically the future of programming
uh you know future programming languages
will be concurrent they have to be
concurrent
and they'll have a concurrency model
based on immutable state so you know
immutable state you know being uh one of
the properties they've inherited from
functional programming languages you
might not be using functional
programming languages on a day-to-day
basis but
using you know the paradigms and the
principles and adopting them with your
main
mainstream technologies will make you
much better programmer and they'll make
you much more efficient and productive
earlier on we mentioned though that
immutability there was a speed penalty
right so how do we address that so with
immutability indeed you have a speed
penalty
but you know the speed penalty
becomes even more serious when you start
looking at amdahl's law
um
every one and a half years until
the mid-2000s uh chips were getting you
know becoming twice as fast
uh then amdahl's law you know because of
ambassador they've hit the limit and now
you need to deal you know you gain speed
through multi-core
and with multi-core programming you need
a different approach and what you do is
you start parallelizing your
computations
so you know desktops
will very soon have 64 cores you know
we'll be seeing
uh machines with a million cores
within their lifetimes
you know you start utilizing instead of
you're making one a single threaded
program which runs extremely fast you
now start parallelizing your programs
and so you start breaking up your
computations into many smaller
computations
and
this you know the only way to do that
is uh concurrency rented programming
with uh immutable states
with a concurrency model based on
immutable state
uh yeah that you you seem to have uh
yeah you've seen
scenes have
been hung by your own what was it called
busted yes