The Erlang Concurrency Model (L22)

Question 1

Traditionally, each thread is treated as a single entity along with the other threads of the same program.

Answer 1

False - traditionally treated as separate entities.

Question 2

Treating each thread as a separate entity scales nicely, as the OS has full control.

Answer 2

False - too many threads leads to slices of allocated time that are too small.

Question 3

The Erlang virtual machine creates its own super-lightweight threads. What are the pros to this?

Answer 3

A massive number of threads may be created with almost no resource overhead.

Question 4

The Erlang virtual machine creates its own super-lightweight threads. What are the cons to this?

Answer 4

All threads must share the same block of CPU time.

Question 5

How many functions does Erlang provide for creating tasks and communicating between them? What are they?

Answer 5

3 - spawn, send, receive.

Question 6

What name is given to Erlangs lightweight threads?

Answer 6

Processes.

Question 7

What does the spawn function return?

Answer 7

The process ID of the new process.

Question 8

Give an example of using the spawn function to create a process.

Answer 8

Pid = spawn(module, func, args).

Question 9

Child processes may execute prior to the parent process that created them.

Answer 9

True - there is no guarantee.

Question 10

Concurrent Erlang application logic may depend on a rigid send/receive order.

Answer 10

False.

Question 11

What do X & Y represent in the below send function call?
X ! Y

Answer 11

X is the process ID of the target process, ! is the send operator, Y is the message (one or more data items).

Question 12

Receive blocks are always written within the listen() function.

Answer 12

False - “find” is an arbitrary function name.

Question 13

What data structures can the following receive block accept?
listen() ->
receive
{dog, Name} ->
“Mr” ++ Name;
{cat, Name} ->
“Ms” ++ Name
end.

Answer 13

Tuples that either begin with the dog or cat atom (and which have 1 other element).

Question 14

Receive blocks are terminated by what keyword?

Answer 14

end.

Question 15

Receive blocks execute for all messages in the queue that match one of its patterns.

Answer 15

False, the listen function terminates after the first match.

Question 16

Messages that don’t match any pattern of the receive block are deleted.

Answer 16

False - they go into a “save” queue that may be checked again at a later time.

Question 17

Receive functions may only be invoked periodically.

Answer 17

False - they may be invoked continously.

Question 18

What type of application continuously invokes receive operations?

Answer 18

Server applications (web or dbms server)

Question 19

How are receive blocks continuously invoked if Erlang has limited support for iteration?

Answer 19

Using recursion: the receive block calls its own wrapper function.

Question 20

How does a process obtain its own process ID for two way communication?

Answer 20

Using self().

Question 21

Receive blocks may be nested.

Answer 21

True.

Question 22

Implement a timeout option (2000 milliseconds) into the following receive block:
receive
{Msg} -> do_something(Msg)
end.

Answer 22

receive
{Msg} -> do_something(Msg)
after 2000 -> do_something()
end.

Question 23

What does Erlang’s name registration service do?

Answer 23

Allows a process ID to be associated with a name/label.

Question 24

Using Erlang’s name registration service, processes can obtain the ID of all known/unknown concurrent process.

Answer 24

False - not if the name of the other process isn’t known.

Question 25

What function registers a process name with a process ID?

Answer 25

register(atomName, ID)

Question 26

What function removes a process name from the name registration service?

Answer 26

unregister (atomName)

Question 27

What does the following return?
whereis(atomName)

Answer 27

Returns the PID of atomName, or undefined if not found.

Question 28

What does the following return?
registered()

Answer 28

A list of all currently registered processes.

Question 29

It is possible to link processes together so that “supervisor” processes can be notified if a monitored process terminates.

Answer 29

True.

Question 30

Use a guard on the following receive pattern so that matching is conditional:
receive {Flag, Name} -> (…)

Answer 30

receive {Flag, Name} [when Flag == 1] -> (…)