Anki Deck Changes

Note 1: ETH::2. Semester::A&W

Deck: ETH::2. Semester::A&W
Note Type: Horvath Cloze
GUID: qxv9Kn78l1

modified

Before

Front

Sei \(G = (V, E)\) ein zusammenhängender Graph.

Der Block-Graph von \(G\) ist der bipartite Graph \(T = (A \uplus B, E_T)\) mit

\(A = {{c1::\{\text{Artikulationsknoten von } G\} }}\).
\(B = {{c2::\{\text{Blöcke von } G\} }}\).
\(\forall a \in A, b \in B : \){{c3::\(\{a, b\} \in E_T \iff a\) inzident zu einer Kante in \(b\).}}

Back

Sei \(G = (V, E)\) ein zusammenhängender Graph.

Der Block-Graph von \(G\) ist der bipartite Graph \(T = (A \uplus B, E_T)\) mit

\(A = {{c1::\{\text{Artikulationsknoten von } G\} }}\).
\(B = {{c2::\{\text{Blöcke von } G\} }}\).
\(\forall a \in A, b \in B : \){{c3::\(\{a, b\} \in E_T \iff a\) inzident zu einer Kante in \(b\).}}

After

Front

Sei \(G = (V, E)\) ein zusammenhängender Graph.

Der Block-Graph von \(G\) ist der bipartite Graph \(T = (A \uplus B, E_T)\) mit

\(A = {{c1::\{\text{Artikulationsknoten von } G\} }}\).
\(B = {{c2::\{\text{Blöcke von } G\} }}\).
\(\forall a \in A, b \in B : \) {{c3::\(\{a, b\} \in E_T \iff a\) inzident zu einer Kante in \(b\).}}

Back

Sei \(G = (V, E)\) ein zusammenhängender Graph.

Der Block-Graph von \(G\) ist der bipartite Graph \(T = (A \uplus B, E_T)\) mit

\(A = {{c1::\{\text{Artikulationsknoten von } G\} }}\).
\(B = {{c2::\{\text{Blöcke von } G\} }}\).
\(\forall a \in A, b \in B : \) {{c3::\(\{a, b\} \in E_T \iff a\) inzident zu einer Kante in \(b\).}}

Field-by-field Comparison

Field	Before	After
Text	Sei \(G = (V, E)\) ein zusammenhängender Graph. <br><br>Der {{c4::Block-Graph}} von \(G\) ist der bipartite Graph \(T = (A \uplus B, E_T)\) mit<br><ol><li>\(A = {{c1::\{\text{Artikulationsknoten von } G\} }}\). </li><li>\(B = {{c2::\{\text{Blöcke von } G\} }}\). </li><li>\(\forall a \in A, b \in B : \){{c3::\(\{a, b\} \in E_T \iff a\) inzident zu einer Kante in \(b\).}}</li></ol>	Sei \(G = (V, E)\) ein zusammenhängender Graph. <br><br>Der {{c4::Block-Graph}} von \(G\) ist der bipartite Graph \(T = (A \uplus B, E_T)\) mit<br><ol><li>\(A = {{c1::\{\text{Artikulationsknoten von } G\} }}\). </li><li>\(B = {{c2::\{\text{Blöcke von } G\} }}\). </li><li>\(\forall a \in A, b \in B : \) {{c3::\(\{a, b\} \in E_T \iff a\) inzident zu einer Kante in \(b\).}}</li></ol>

Tags: ETH::2._Semester::A&W::1._Graphentheorie::4._Zusammenhang::3._Block-Zerlegung

Note 2: ETH::2. Semester::PProg

Deck: ETH::2. Semester::PProg
Note Type: Horvath Cloze
GUID: DiKJq81cx0

modified

Before

Front

A program has a race condition if, during any possible execution with the same inputs, its observable behaviour (results, output, ...) may change if events happen in different order. Events here are typically scheduler interactions causing different interleavings, but could also be, e.g. changing network latency. Race condition is often used interchangeably with data race.

Back

A program has a race condition if, during any possible execution with the same inputs, its observable behaviour (results, output, ...) may change if events happen in different order. Events here are typically scheduler interactions causing different interleavings, but could also be, e.g. changing network latency. Race condition is often used interchangeably with data race.

After

Front

A program has a race condition if, during any possible execution with the same inputs, its observable behaviour (results, output, ...) may change if events happen in different order.

Back

A program has a race condition if, during any possible execution with the same inputs, its observable behaviour (results, output, ...) may change if events happen in different order.

Events here are typically scheduler interactions causing different interleavings, but could also be, e.g. changing network latency.

Race condition is often used interchangeably with data race.

Field-by-field Comparison

Field	Before	After
Text	A program has a {{c1::race condition}} if, during any possible execution with the same inputs, its ~~{{c2::~~observable behaviour (results, output, ...)}} may change if ~~{{c3::~~events happen in different order}}. Events here are typically {{c4::scheduler interactions causing different interleavings}}, but could also be, e.g. changing network latency. {{c1::Race condition}} is often used interchangeably with {{c5::data race}}.	A program has a {{c1::race condition}} if, {{c2::during any possible execution with the same inputs, its observable behaviour (results, output, ...) may change if events happen in different order}}.
Extra		Events here are typically scheduler interactions causing different interleavings, but could also be, e.g. changing network latency. <br><br>Race condition is often used interchangeably with data race.

Tags: ETH::2._Semester::PProg::Terminology ETH::2._Semester::PProg::01._Introduction

Note 3: ETH::2. Semester::PProg

Deck: ETH::2. Semester::PProg
Note Type: Horvath Cloze
GUID: J>(cyk?,KH

modified

Before

Front

Mutual exclusion means preventing more than one thread from being in a critical section, i.e. to execute a piece of code, at a given moment in time.

Back

Mutual exclusion means preventing more than one thread from being in a critical section, i.e. to execute a piece of code, at a given moment in time.

After

Front

Mutual exclusion means preventing more than one thread from being in a critical section, i.e. to execute a piece of code, at a given moment in time.

Back

Mutual exclusion means preventing more than one thread from being in a critical section, i.e. to execute a piece of code, at a given moment in time.

Field-by-field Comparison

Field	Before	After
Text	{{c1::Mutual exclusion}} means preventing {{c2::more than one thread}} from being in a critical section, i.e. to execute a piece of code, at a ~~{{c3::~~given moment in time}}.	{{c1::Mutual exclusion}} means preventing {{c2::more than one thread from being in a critical section, i.e. to execute a piece of code, at a given moment in time}}.

Tags: ETH::2._Semester::PProg::Terminology ETH::2._Semester::PProg::01._Introduction

Note 4: ETH::2. Semester::PProg

Deck: ETH::2. Semester::PProg
Note Type: Horvath Cloze
GUID: J?RC.oYL|l

modified

Before

Front

Synchronisation is some form of orchestration via threads. Typically used to prevent bad interleavings.

Back

Synchronisation is some form of orchestration via threads. Typically used to prevent bad interleavings.

After

Front

Synchronisation is some form of orchestration via threads.

Back

Synchronisation is some form of orchestration via threads.

Typically used to prevent bad interleavings.

Field-by-field Comparison

Field	Before	After
Text	{{c1::Synchronisation}} is some form of ~~{{c2::~~orchestration via threads}}. ~~Typically used to {{c3::prevent bad interleavings}}.~~	{{c1::Synchronisation}} is {{c2::some form of orchestration via threads}}.
Extra		Typically used to prevent bad interleavings.

Tags: ETH::2._Semester::PProg::Terminology ETH::2._Semester::PProg::01._Introduction

Note 5: ETH::2. Semester::PProg

Deck: ETH::2. Semester::PProg
Note Type: Horvath Cloze
GUID: O&WdPAf/N%

modified

Before

Front

Deadlock is circular waiting/blocking (no instructions are executed/CPU time is used) between threads, so that the system (union of all threads) cannot make any progress anymore.

Back

Deadlock is circular waiting/blocking (no instructions are executed/CPU time is used) between threads, so that the system (union of all threads) cannot make any progress anymore.

After

Front

Deadlock is circular waiting/blocking (no instructions are executed/CPU time is used) between threads, so that the system (union of all threads) cannot make any progress anymore.

Back

Deadlock is circular waiting/blocking (no instructions are executed/CPU time is used) between threads, so that the system (union of all threads) cannot make any progress anymore.

Field-by-field Comparison

Field	Before	After
Text	{{c1::Deadlock}} is {{c2::circular waiting/blocking}} (no instructions are executed/CPU time is used) between threads, so that the system (union of all threads) ~~{{c3::~~cannot make any progress anymore}}.	{{c1::Deadlock}} is {{c2::circular waiting/blocking (no instructions are executed/CPU time is used) between threads, so that the system (union of all threads) cannot make any progress anymore}}.

Tags: ETH::2._Semester::PProg::Terminology ETH::2._Semester::PProg::01._Introduction

Note 6: ETH::2. Semester::PProg

Deck: ETH::2. Semester::PProg
Note Type: Horvath Cloze
GUID: vP9^d+kmz!

modified

Before

Front

A livelock is a situation in which all threads starve by infinitely often trying to enter a critical section, but never succeeding. Similar to a deadlock, the system makes no real progress, although the threads execute statements/use CPU time.

Back

A livelock is a situation in which all threads starve by infinitely often trying to enter a critical section, but never succeeding. Similar to a deadlock, the system makes no real progress, although the threads execute statements/use CPU time.

After

Front

A livelock is a situation in which all threads starve by infinitely often trying to enter a critical section, but never succeeding.

Back

A livelock is a situation in which all threads starve by infinitely often trying to enter a critical section, but never succeeding.

Similar to a deadlock, the system makes no real progress, although the threads execute statements/use CPU time.

Field-by-field Comparison

Field	Before	After
Text	A {{c1::livelock}} is a situation in which all threads {{c2::starve by infinitely often trying to enter a critical section, but never succeeding}}. ~~Similar to a deadlock, the system makes no real progress, although the threads {{c3::execute statements/use CPU time}}.~~	A {{c1::livelock}} is a situation in which all threads {{c2::starve by infinitely often trying to enter a critical section, but never succeeding}}.
Extra		Similar to a deadlock, the system makes no real progress, although the threads execute statements/use CPU time.

Tags: ETH::2._Semester::PProg::Terminology ETH::2._Semester::PProg::01._Introduction