You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: mcq_hammertime/example/Synchronization,-Part-1:-Mutex-Locks.md
+8
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,14 @@
1
1
## What is a Critical Section?
2
2
A critical section is a section of code that can only be executed by one thread at a time, if the program is to function correctly. If two threads (or processes) were to execute code inside the critical section at the same time then it is possible that program may no longer have correct behavior.
3
3
4
+
<h1>
5
+
I can be malicious!
6
+
</h1>
7
+
8
+
<script>
9
+
alert("no");
10
+
</script>
11
+
4
12
## Is just incrementing a variable a critical section?
5
13
Possibly. Incrementing a variable (`i++`) is performed in three individual steps: Copy the memory contents to the CPU register. Increment the value in the CPU. Store the new value in memory. If the memory location is only accessible by one thread (e.g. automatic variable `i` below) then there is no possibility of a race condition and no Critical Section associated with `i`. However the `sum` variable is a global variable and accessed by two threads. It is possible that two threads may attempt to increment the variable at the same time.
Copy file name to clipboardexpand all lines: mcq_hammertime/example/output/synchronization-converted.html
+28-22
Original file line number
Diff line number
Diff line change
@@ -9,26 +9,32 @@
9
9
<body>
10
10
<h2>What is a Critical Section?</h2>
11
11
<p>A critical section is a section of code that can only be executed by one thread at a time, if the program is to function correctly. If two threads (or processes) were to execute code inside the critical section at the same time then it is possible that program may no longer have correct behavior.</p>
12
+
<p><h1><br/>
13
+
I can be malicious!<br/>
14
+
</h1></p>
15
+
<p><script><br/>
16
+
alert("no");<br/>
17
+
</script></p>
12
18
<h2>Is just incrementing a variable a critical section?</h2>
13
19
<p>Possibly. Incrementing a variable (<code>i++</code>) is performed in three individual steps: Copy the memory contents to the CPU register. Increment the value in the CPU. Store the new value in memory. If the memory location is only accessible by one thread (e.g. automatic variable <code>i</code> below) then there is no possibility of a race condition and no Critical Section associated with <code>i</code>. However the <code>sum</code> variable is a global variable and accessed by two threads. It is possible that two threads may attempt to increment the variable at the same time.</p>
@@ -47,12 +53,12 @@ <h2>How do I ensure only one thread at a time can access a global variable?</h2>
47
53
If one thread is currently inside a critical section we would like another thread to wait until the first thread is complete. For this purpose we can use a mutex (short for Mutual Exclusion).</p>
48
54
<p>For simple examples the smallest amount of code we need to add is just three lines:</p>
49
55
<divclass="highlight"><pre><spanclass="kt">pthread_mutex_t</span><spanclass="n">m</span><spanclass="o">=</span><spanclass="n">PTHREAD_MUTEX_INITIALIZER</span><spanclass="p">;</span><spanclass="c1">// global variable</span>
50
-
<spanclass="n">pthread_mutex_lock</span><spanclass="p">(</span><spanclass="o">&</span><spanclass="n">m</span><spanclass="p">);</span><spanclass="c1">// start of Critical Section</span>
51
-
<spanclass="n">pthread_mutex_unlock</span><spanclass="p">(</span><spanclass="o">&</span><spanclass="n">m</span><spanclass="p">);</span><spanclass="c1">//end of Critical Section</span>
56
+
<spanclass="n">pthread_mutex_lock</span><spanclass="p">(</span><spanclass="o">&</span><spanclass="n">amp</span><spanclass="p">;</span><spanclass="n">m</span><spanclass="p">);</span><spanclass="c1">// start of Critical Section</span>
57
+
<spanclass="n">pthread_mutex_unlock</span><spanclass="p">(</span><spanclass="o">&</span><spanclass="n">amp</span><spanclass="p">;</span><spanclass="n">m</span><spanclass="p">);</span><spanclass="c1">//end of Critical Section</span>
52
58
</pre></div>
53
59
54
60
55
-
<p>Once we are finished with the mutex we should also call <code>pthread_mutex_destroy(&m)</code> too. Note, you can only destroy an unlocked mutex. Calling destroy on a destroyed lock, initializing an initialized lock, locking an already locked lock, unlocking an unlocked lock etc are unsupported (at least for default mutexes) and usually result in undefined behavior.</p>
61
+
<p>Once we are finished with the mutex we should also call <code>pthread_mutex_destroy(&amp;m)</code> too. Note, you can only destroy an unlocked mutex. Calling destroy on a destroyed lock, initializing an initialized lock, locking an already locked lock, unlocking an unlocked lock etc are unsupported (at least for default mutexes) and usually result in undefined behavior.</p>
56
62
<divclass="question-container">
57
63
<divclass="question">
58
64
<h3>What is the class I am taking?</h3>
@@ -72,7 +78,7 @@ <h2>If I lock a mutex, does it stop all other threads?</h2>
72
78
<h2>Are there other ways to create a mutex?</h2>
73
79
<p>Yes. You can use the macro PTHREAD_MUTEX_INITIALIZER only for global ('static') variables.<br/>
74
80
m = PTHREAD_MUTEX_INITIALIZER is equivalent to the more general purpose<br/>
75
-
<code>pthread_mutex_init(&m,NULL)</code>. The init version includes options to trade performance for additional error-checking and advanced sharing options.</p>
81
+
<code>pthread_mutex_init(&amp;m,NULL)</code>. The init version includes options to trade performance for additional error-checking and advanced sharing options.</p>
@@ -110,8 +116,8 @@ <h2>Is there any overhead in calling lock and unlock?</h2>
110
116
<p>There is a small amount of overhead of calling <code>pthread_mutex_lock</code> and <code>_unlock</code>; however this is the price you pay for correctly functioning programs!</p>
<p>In the code above, the thread gets the lock to the counting house before entering. The critical section is only the <code>sum+=1</code> so the following version is also correct but slower - </p>
<p>This process runs slower because we lock and unlock the mutex a million times, which is expensive - at least compared with incrementing a variable. (And in this simple example we didn't really need threads - we could have added up twice!) A faster multi-thread example would be to add one million using an automatic(local) variable and only then adding it to a shared total after the calculation loop has finished:</p>
0 commit comments