Go on. Explore!

lvl 0 • 0 xp

lvl 1

Home Market Decks Interests

5.3 Concurrency Elixir(Theory)

memorize.ai (lvl 286)

(0)

32 cards

()

Section 1

Preview this deck

once

Front

1 / 32

Elixir

0.0

0 reviews

5			0
4			0
3			0
2			0
1			0

Active users

All-time users

Favorites

Last updated

6 years ago

Date created

Mar 1, 2020

Cards (32)

Section 1

(32 cards)

once

Front

receive give access to read a message only {...}

Back

implementation

Front

{...} functions are usually private and run in the server process.

Back

pull

Front

With receiver you can {...} all the messages from the mailbox to a single list

Back

atom, name

Front

The following rules apply to registered names: 1. The name can only be an {...} 2. A single process can have only one name. 3. Two processes can't have the same {...}

Back

true

Front

true/false In single core CPU, you may get concurrency

Back

concurrency

Front

{...} means multiple tasks which start, run, and complete in overlapping time periods, in no specific order.

Back

false

Front

true/false The server process loop is CPU-intensive.

Back

abstractions

Front

The data should be modeled using pure functional {...}

Back

performance

Front

having many processes frequently send big messages may affect system {....} (A list of a million complex structures is big)

Back

recursion

Front

Server processes are powered by endless {...}

Back

false

Front

true/false Processes share memory

Back

true

Front

true/false a server process is internally sequential.

Back

abstractions

Front

A stateful process used on top of functional {...}

Back

memory

Front

A server powered by this loop handles only messages that are in the form {:message, something}. All other messages remain in the process mailbox forever, taking up {...} space for no reason.

Back

messages

Front

Processes communicate via {...}

Back

processes

Front

Concurrency is the composition of independently executing {...}

Back

computation

Front

parallelism is the simultaneous execution of (possibly related) {....}

Back

arrive

Front

The goal is to make the server handle messages at least as fast as they {...}

Back

executed

Front

Each process gets a small execution window ~2,000 function calls. After which it's preempted and another process is {...}

Back

parallelism

Front

{...} is when multiple tasks OR several part of a unique task literally run at the same time, e.g. on a multi-core processor.

Back

interface

Front

{...} functions are public and are executed in the caller process.

Back

true

Front

True/false In single core CPU, you may get concurrency but NOT parallelism.

Back

true

Front

true/false the caller process runs independently and has no access to any data from the spawned processes.

Back

recursion

Front

The GenServer abstraction again relies on {...}

Back

concurrency

Front

{...} is about dealing with lots of things at once.

Back

10s

Front

if you issue five asynchronous query requests(2s) to a single server process, they will be handled one by one, and the result of the last query will come after {...} seconds. [POOL will help]

Back

true

Front

true/false By default, BEAM uses only as many schedulers as there are logical processors available

Back

true

Front

true/false although multiple processes may run in parallel, a single process is always sequential

Back

false

Front

true/false In single core CPU, you may get parallelism

Back

true

Front

true/false Loog unknown messages is a good practice

Back

isolated

Front

Processes are completely {...}

Back

parallelism

Front

{...} is about doing lots of things at once.

Back