Second round of human edits made for hire through Amazon Mechanical

Turk to improve machine generated transcript.

Sponsored by:	FreeBSD Foundation

1 files changed, 150 insertions, 155 deletions

diff --git a/en_US.ISO8859-1/captions/2009/asiabsdcon/rao-kernellocking-2.sbv b/en_US.ISO8859-1/captions/2009/asiabsdcon/rao-kernellocking-2.sbv
index 16f08a914a..bf785730a9 100644
--- a/en_US.ISO8859-1/captions/2009/asiabsdcon/rao-kernellocking-2.sbv
+++ b/en_US.ISO8859-1/captions/2009/asiabsdcon/rao-kernellocking-2.sbv
@@ -1,8 +1,8 @@
 0:00:00.530,0:00:01.590
-So, basically,
+So basically,
 
 0:00:04.590,0:00:10.029
-we are going to look mainly in this second part
+we are going to look, mainly in this second part,
 at how to
 
 0:00:10.029,0:00:11.519
@@ -15,32 +15,32 @@ locking problems
 that categorize in the kernel.
 
 0:00:17.910,0:00:24.410
-Here there are described two kinds of problems 
-you can get with locks, that are pretty much common
+Here, there are described two kinds of problems 
+you can get with locks, that are pretty much common.
 
 0:00:24.410,0:00:27.859
-The first one is called Lock Order Reversal
+The first one is called Lock Order Reversal (LOR).
 
 0:00:27.859,0:00:30.140
-when you have for example a thread A
+When you have for example a thread A,
 
 0:00:30.140,0:00:32.340
 which owns
 
 0:00:32.340,0:00:35.870
-a lock code, for example, L1
+a lock code, for example L1
 
 0:00:35.870,0:00:37.920
 and another thread B
 
 0:00:37.920,0:00:40.070
-which owns another lock, L2
+which owns the lock, L2
 
 0:00:40.070,0:00:43.150
-Then thread A tries to
+Then thread A tries to..
 
 0:00:43.150,0:00:44.730
-Right, it's wrong.
+Right.. it's wrong.
 
 0:00:44.730,0:00:46.220
 The slide is wrong.
@@ -96,7 +96,7 @@ knows that
 locks should maintain
 
 0:01:32.910,0:01:34.319
-an ordering regard of each other.
+an ordering in regard of each other.
 
 0:01:34.319,0:01:38.859
 That's not very simple when
@@ -110,25 +110,26 @@ that there are 3 kinds of classes of locks
 
 0:01:44.850,0:01:49.180
 is going to count because you can 
-never mix two different kinds of locks
+never mix two different kinds of locks.
 
 0:01:49.180,0:01:50.680
-for example
+For example
 
 0:01:50.680,0:01:51.610
-a spin lock
+a spinlock
 
 0:01:51.610,0:01:53.770
-and a mutex.
+and a mutex
 
 0:01:53.770,0:01:59.120
-You can mix in this way.
+can be mixed in this way.
 
 0:01:59.120,0:02:01.720
-
+You can have the mutex first and the spinlock later,
+while the opposite is not actually true.
 
 0:02:01.720,0:02:07.060
-So, you will see that this kind 
+So, you will see that these kind 
 of deadlocks are possible
 
 0:02:07.060,0:02:09.290
@@ -141,26 +142,26 @@ like for example 2 mutex or 2 spin mutex,
 or such.
 
 0:02:14.569,0:02:16.090
-Um...
+
 
 0:02:16.090,0:02:17.409
-Also
+Also,
 
 0:02:17.409,0:02:19.949
-Even if it's not very well documented,
+even if it's not very well documented,
 
 0:02:19.949,0:02:22.880
-for example, spin locks,
+for example spinlocks
 
 0:02:22.880,0:02:26.599
-in previous deep, as a way to 
+in FreeBSD, have a way to 
 identify such kind of deadlocks.
 
 0:02:26.599,0:02:27.619
-And it's pretty much implemented...
+And it's pretty much implemented.
 
 0:02:27.619,0:02:29.709
-a very much in it would
+
 
 0:02:29.709,0:02:32.449
 It's a feature enabled in the code.
@@ -178,7 +179,7 @@ if it exceeds
 an exaggerated result,
 
 0:02:41.379,0:02:47.870
-it means that they are probable 
+it means that they are probably 
 under a deadlock and the system panics. 
 
 0:02:47.870,0:02:52.489
@@ -224,7 +225,7 @@ you can end up having some threads
 sleeping on this wait channel
 
 0:03:30.569,0:03:34.589
-and nobody is going to wake up them again.
+and nobody is going to wake them up again.
 
 0:03:34.589,0:03:37.629
 This is usually called missed wakeup
@@ -240,10 +241,10 @@ The problem is that
 
 0:03:46.719,0:03:52.109
 it's very difficult to differentiate 
-between missed wakeup and,
+between missed wakeup and
 
 0:03:52.109,0:03:53.480
-for example,
+for example
 
 0:03:53.480,0:03:56.189
 forever sleep
@@ -256,7 +257,7 @@ that is not likely to be awaken.
 
 0:04:01.859,0:04:07.109
 So these kind of deadlocks are 
-very difficult to be discovered
+very very difficult to be discovered
 
 0:04:07.109,0:04:11.669
 and will require some bit of 
@@ -278,7 +279,7 @@ kernel systems
 and some things integrated into the debugger.
 
 0:04:22.240,0:04:22.979
-Um,
+
 
 0:04:22.979,0:04:25.520
 In FreeBSD,
@@ -292,7 +293,7 @@ with kernel problems.
 
 0:04:32.080,0:04:36.539
 The first one (and the most important) 
-is called witness.
+is called WITNESS.
 
 0:04:36.539,0:04:39.169
 It was introduced 
@@ -301,7 +302,7 @@ It was introduced
 in the context of SMPng
 
 0:04:42.080,0:04:44.979
-and has been written in the recent past, 
+and has been rewritten in the recent past, 
 
 0:04:44.979,0:04:47.919
 mainly by a contribution of
@@ -313,7 +314,7 @@ Isilon systems.
 They contributed back then
 
 0:04:52.270,0:04:54.989
-to the writing of witness.
+to the writing of WITNESS.
 
 0:04:54.989,0:04:57.389
 This subsystem is very important
@@ -322,7 +323,7 @@ This subsystem is very important
 because it tracks down exactly every order
 
 0:05:02.730,0:05:03.949
-of the locks
+of the locks.
 
 0:05:03.949,0:05:07.810
 So that, if there is an ordering violation like a LOR,
@@ -356,7 +357,7 @@ Doing that,
 we can identify 
 
 0:05:36.539,0:05:38.419
-deadlocks possible
+deadlocks, possibly
 
 0:05:38.419,0:05:39.500
 even
@@ -368,7 +369,7 @@ on the
 reader's path.
 
 0:05:45.529,0:05:49.609
-We could say that witness is pretty big, 
+We could say that WITNESS is pretty big, 
 
 0:05:49.609,0:05:52.289
 so activating it
@@ -381,10 +382,10 @@ It's mainly used when you are going to
 develop a new feature in the kernel
 
 0:05:59.929,0:06:02.110
-and you are going to test it heavily,
+and you are going to test it heavily.
 
 0:06:02.110,0:06:05.479
-in particular if it has 
+In particular if it has 
 
 0:06:05.479,0:06:06.819
 some
@@ -393,7 +394,7 @@ some
 relation to locking.
 
 0:06:10.509,0:06:13.089
-Uh,
+
 
 0:06:13.089,0:06:17.840
 We could also tell that with the new code 
@@ -403,10 +404,10 @@ provided by Isilon and Nokia,
 basically
 
 0:06:19.150,0:06:21.689
-the orad
+
 
 0:06:21.689,0:06:25.479
-offered by witness is greatly reduced to about
+offered by WITNESS is greatly reduced to about
 
 0:06:25.479,0:06:27.699
 the 10th part of 
@@ -415,7 +416,7 @@ the 10th part of
 what we had before.
 
 0:06:30.240,0:06:36.150
-Witness is very good at tracking LOR,
+WITNESS is very good at tracking LOR,
 
 0:06:36.150,0:06:37.849
 but
@@ -448,7 +449,7 @@ and
 basically
 
 0:06:58.879,0:07:04.159
-and basically, it's in the 8th release, 
+it's in the 8th release, 
 we have new features
 
 0:07:04.159,0:07:05.759
@@ -467,18 +468,18 @@ and their orderings
 and
 
 0:07:17.549,0:07:23.550
-and shows some graphs of the relations. 
-Even from the user space, 
+it shows some graphs of the relations
+even from the user space. 
 
 0:07:23.550,0:07:28.550
-you don't have to go into the kernel 
-degubber to look at it's output.
+You don't have to go into the kernel 
+debugger to look at it's output.
 
 0:07:28.550,0:07:35.550
-Well
+
 
 0:07:35.620,0:07:37.380
-...
+
 
 0:07:37.380,0:07:42.250
 Well, I see that sometimes when 
@@ -507,36 +508,36 @@ when a deadlock
 is in the kernel.
 
 0:07:59.590,0:08:02.490
-...
+
 
 0:08:02.490,0:08:03.389
 Usually, 
 
 0:08:03.389,0:08:07.939
 if you want to find a deadlock 
-that's happening in the kernel
+that's happening in the kernel,
 
 0:08:07.939,0:08:10.909
-your first line of analysis start from the DDB
+your first line of analysis starts from the DDB
 
 0:08:10.909,0:08:13.919
 instead of a post-mortem analysis,
 
 0:08:13.919,0:08:16.839
-which is even more important,
+which is even more important.
 
 0:08:16.839,0:08:22.330
-but using DDB you will get more 
+But, using DDB you will get more 
 processes and better information. 
 
 0:08:22.330,0:08:24.970
-Uh,
+
 
 0:08:24.970,0:08:28.499
 The most important unit in order to find the deadlock
 
 0:08:28.499,0:08:34.389
-are the LORs reported by witness in order 
+are the LORs reported by WITNESS in order 
 to see if there is something strange 
 
 0:08:34.389,0:08:36.690
@@ -547,10 +548,10 @@ You want to know the state of all the threads
 that are running on the system that is deadlocking. 
 
 0:08:41.700,0:08:42.900
-...
+
 
 0:08:42.900,0:08:47.050
-You can see that you're deadlocking if you see that
+You can see that you're deadlocking, if you see that
 
 0:08:47.050,0:08:48.070
 on the runqueue
@@ -570,21 +571,21 @@ and you have all the threads sleeping
 in their own containers.
 
 0:09:02.450,0:09:07.850
-You need to know which are exactly locks 
+You need to know which are the exact locks 
 that are acquired
 
 0:09:07.850,0:09:11.270
 in the system
 
 0:09:11.270,0:09:15.570
-and that's something that witness provides,
+and that's something that WITNESS provides
 
 0:09:15.570,0:09:20.720
-and the very important things is 
+and the very important thing is 
 to know why the threads are stopping.
 
 0:09:20.720,0:09:24.250
-So one on the most important things is 
+So one of the most important things is 
 retrieving what the threads were doing
 
 0:09:24.250,0:09:26.320
@@ -594,13 +595,13 @@ when
 they were put asleep.
 
 0:09:28.960,0:09:30.070
-...
+
 
 0:09:30.070,0:09:33.009
 The backtraces of all the threads involved
 
 0:09:33.009,0:09:37.130
-are so printed out in order to identify deadlocks.
+are printed out in order to identify deadlocks.
 
 0:09:37.130,0:09:38.589
 In the case that 
@@ -609,13 +610,13 @@ In the case that
 buffered cache and VFS are 
 
 0:09:42.830,0:09:45.910
-probably parts of the deadlocking 
+probably parts of the deadlocking,
 
 0:09:45.910,0:09:50.790
 you should also print out
 
 0:09:50.790,0:09:53.420
-the info about vnodes 
+the information about vnodes 
 
 0:09:53.420,0:09:58.250
 and what we're interested in is which vnodes are called,
@@ -630,10 +631,10 @@ are actually referenced
 and
 
 0:10:03.530,0:10:10.530
-which way they were called.
+in which way they were called.
 
 0:10:11.030,0:10:13.380
-So 
+So, 
 
 0:10:13.380,0:10:15.770
 this is an example
@@ -648,7 +649,7 @@ thread states
 in the case of a deadlock. 
 
 0:10:20.760,0:10:27.480
-This is an example of a real deadlock
+This is an real example of a deadlock
 
 0:10:27.480,0:10:28.900
 but you can see 
@@ -663,10 +664,10 @@ this is not totally complete.
 But you can see that all the threads are sleeping. 
 
 0:10:38.450,0:10:39.870
-Uh...
+
 
 0:10:39.870,0:10:43.580
-And this one is the message 
+This one is the message 
 
 0:10:43.580,0:10:44.790
 used by the wait channel
@@ -678,7 +679,7 @@ on which they're sleeping on
 or used by
 
 0:10:48.710,0:10:54.480
-the container like the turnsile or the sleep queue. 
+the container like the turnstile or the sleepqueue. 
 
 0:10:54.480,0:10:59.410
 If I recall correctly, it's a forced amount 
@@ -688,7 +689,7 @@ that does deadlocking at some point.
 I'm not really sure
 
 0:11:01.290,0:11:04.190
-because I have to take a look at it. 
+because I should have looked at it. 
 
 0:11:04.190,0:11:08.810
 You can see that the revelant command here 
@@ -698,7 +699,7 @@ is -ps
 that DDB supports.
 
 0:11:11.220,0:11:14.220
-Um,
+
 
 0:11:14.220,0:11:17.520
 Another important thing
@@ -716,43 +717,39 @@ As you can see there,
 usually
 
 0:11:25.210,0:11:31.600
-is because you can add some data structures corrupted 
+its because you can add some data structures corrupted 
 
 0:11:31.600,0:11:34.320
 in the per-CPU datas. 
 
 0:11:34.320,0:11:38.830
-That's a very common situation when you get deadlocks,
+That's a very common situation where you can get deadlocks,
 
 0:11:38.830,0:11:40.280
-because, for example, 
+because, for example,
 
 0:11:40.280,0:11:43.149
 leaving a corrupted LPD will lead 
 
-0:11:43.149,0:11:48.750
-I loved you too much review shellacking double
-falls and things like that about that
-
 0:11:48.750,0:11:55.290
 to you having a bigger massive breakage like 
-double-faults. In general. it's a good idea to 
-look at all the CPUs involved in the system. 
+double-faults and things like that. Usually it's always a
+good idea to look at all the CPUs involved in the system. 
 
 0:11:55.290,0:11:57.310
 The command
 
 0:11:57.310,0:12:00.120
-is ""show allpcpu""
+is """"-show allpcpu"".
 
 0:12:00.120,0:12:04.960
-Um,
+
 
 0:12:04.960,0:12:06.959
 This one
 
 0:12:06.959,0:12:12.009
-this one is a witness specific command -show alllocks 
+is a WITNESS specific command ""-show alllocks""
 and it's going to show all the locks, 
 
 0:12:12.009,0:12:13.130
@@ -771,7 +768,7 @@ a mount,
 and the thread is this one, 
 
 0:12:21.270,0:12:23.660
-what lock is holding, 
+what the lock is holding, 
 
 0:12:23.660,0:12:24.970
 that's the address 
@@ -783,7 +780,7 @@ and where it was acquired.
 It gives you lines and file. 
 
 0:12:31.140,0:12:32.770
-...
+
 
 0:12:32.770,0:12:34.730
 Actually,
@@ -792,7 +789,7 @@ Actually,
 that's just possible
 
 0:12:37.620,0:12:40.859
-with witness, because otherwise, 
+with WITNESS, because otherwise, 
 
 0:12:40.859,0:12:44.410
 trying to keep the oldest information 
@@ -806,13 +803,13 @@ Then, the most important thing is
 the backtrace for any thread. 
 
 0:12:59.730,0:13:01.150
-...
+
 
 0:13:01.150,0:13:03.390
 It's going to show the backtrace
 
 0:13:03.390,0:13:05.700
-for old threads.
+for all the threads.
 
 0:13:05.700,0:13:08.380
 the seas
@@ -827,7 +824,7 @@ the thread with these addresses TID and PID
 basically got sleeping 
 
 0:13:15.350,0:13:17.140
-on a pnode.
+on a vnode.
 
 0:13:17.140,0:13:22.020
 You will see that the backend in this case is FFF
@@ -839,7 +836,7 @@ and
 that's the context switching function, 
 
 0:13:25.729,0:13:26.900
-next
+
 
 0:13:26.900,0:13:32.220
 those are the sleepqueues of the containter 
@@ -867,10 +864,11 @@ you will have a lot of these kinds of traces,
 but they are very important 
 
 0:13:53.079,0:13:59.270
-so as developers to understand what is going on. 
+for the developers in order to understand 
+what is going on. 
 
 0:13:59.270,0:14:02.590
-This ones are the locked vnodes 
+These ones are the locked vnodes 
 
 0:14:02.590,0:14:05.830
 that are also very important when 
@@ -891,10 +889,10 @@ they are specific
 to some handling of the vnodes such as recycling, 
 
 0:14:23.850,0:14:26.020
-and completely freeing
+and completely freeing.
 
 0:14:26.020,0:14:27.290
-that's the mount point
+That's the mount point
 
 0:14:27.290,0:14:28.770
 where the vnodes
@@ -927,7 +925,7 @@ For example, it tells you that
 the lock
 
 0:14:52.830,0:14:55.040
-the lock is in exclusive mode 
+is in exclusive mode 
 
 0:14:55.040,0:14:56.280
 and
@@ -942,13 +940,13 @@ on its queues.
 That's also
 
 0:15:04.090,0:15:06.370
-the node number
+the node number.
 
 0:15:06.370,0:15:09.140
-...
+
 
 0:15:09.140,0:15:13.880
-there are also under information you could receive 
+There is also other information you could receive 
 from the DDB linked to, for example, 
 
 0:15:13.880,0:15:16.980
@@ -961,18 +959,18 @@ like sleep chains,
 for any
 
 0:15:19.310,0:15:24.250
-wait channel if you have the address
+wait channel, if you have the address
 
 0:15:24.250,0:15:27.150
-and, for example,
+and for example,
 
 0:15:27.150,0:15:32.650
 you can also print the wall table of 
-the lock relations from witness 
+the lock relations from WITNESS 
 
 0:15:32.650,0:15:38.010
 but it's mostly never useful 
-because you already know that. 
+because you should already know that. 
 
 0:15:38.010,0:15:41.100
 So you will just need to know which is the one 
@@ -981,14 +979,12 @@ So you will just need to know which is the one
 that
 
 0:15:41.980,0:15:43.019
-um,
+
 
 0:15:43.019,0:15:47.750
-can give trouble.
+can give the trouble.
 
 0:15:47.750,0:15:51.640
-if you're going to say I mean some problem
-is a problem
 
 0:15:51.640,0:15:53.980
 So if you are going to submit some problems 
@@ -1020,8 +1016,8 @@ I think that
 it is a very good thing to talk about it. 
 
 0:16:25.670,0:16:31.420
-Along with the witness, we have another 
-mechanism that could help us,
+Along with the WITNESS, we have another 
+important mechanism that could help us with deadlocks
 
 0:16:31.420,0:16:34.620
 and it's called KTR. 
@@ -1030,17 +1026,17 @@ and it's called KTR.
 KTR is
 
 0:16:36.100,0:16:40.630
-basically a logger of events,
+basically a logger, a kernel logger, of events.
 
 0:16:40.630,0:16:42.550
-it's
+It's
 
 0:16:42.550,0:16:45.090
 highly configurable, 
 
 0:16:45.090,0:16:48.280
 as you can, for example, 
-handle different classes of events, 
+handle different classes of events. 
 
 0:16:48.280,0:16:53.940
 In FreeBSD we have 
@@ -1071,7 +1067,7 @@ enable several classes,
 like
 
 0:17:13.610,0:17:16.470
-the time class of the KTR 
+the ten classes of the KTR 
 
 0:17:16.470,0:17:21.000
 and then you are just interested in three of them 
@@ -1114,7 +1110,7 @@ and not the information,
 for example,
 
 0:17:48.390,0:17:50.160
-a string,
+the strings,
 
 0:17:50.160,0:17:55.000
 it doesn't make copies, you need to just pass
@@ -1139,10 +1135,10 @@ you can also look at it from the user space
 through the ktrdump interface. 
 
 0:18:13.430,0:18:15.820
-...
+
 
 0:18:15.820,0:18:17.030
-And now...
+
 
 0:18:17.030,0:18:19.669
 Why is that important for locking? 
@@ -1163,8 +1159,8 @@ on which CPU branches,
 and the order it happened in.
 
 0:18:30.020,0:18:34.580
-and this is very important when you're 
-going to track down for example races, 
+This is very important when you're 
+going to track down for example traces, 
 
 0:18:34.580,0:18:37.720
 when you are not sure about the order of operations and
@@ -1185,14 +1181,14 @@ a typical trace of KTR,
 where you have 
 
 0:18:52.410,0:18:56.890
-the CPU where the event happened, the index, 
+the CPU where the event happened, thats the index, 
 
 0:18:56.890,0:18:58.620
 that's a timestamp, 
 
 0:18:58.620,0:19:03.400
 I think it's retrieved directly from the TSC,
-but i'm not actually sure. 
+but i'm actually not sure. 
 
 0:19:03.400,0:19:04.889
 In this case, 
@@ -1202,7 +1198,7 @@ i was tracking down the scheduler class,
 
 0:19:10.210,0:19:16.100
 so I was interested mainly in scheduler 
-workloads and i could see
+workloads and I could see
 
 0:19:16.100,0:19:19.210
 for example
@@ -1238,10 +1234,10 @@ this one
 and other things. 
 
 0:19:46.420,0:19:48.770
-Well
+
 
 0:19:48.770,0:19:50.820
-you can enable it
+You can enable
 
 0:19:50.820,0:19:55.280
 the option KTR, but you must handle it carefully.
@@ -1266,7 +1262,7 @@ enough entries
 to have a reliable tracking. 
 
 0:20:11.500,0:20:13.580
-...
+
 
 0:20:13.580,0:20:16.780
 For example, if you are going to track a lot of events,
@@ -1293,23 +1289,23 @@ let you compile some classes,
 or mask them,
 
 0:20:38.370,0:20:43.770
-or mask a CPU, 
+or even mask the CPU. 
 
 0:20:43.770,0:20:46.289
-if you have a big SMP environment, 
+If you have a big SMP environment, 
 
 0:20:46.289,0:20:50.160
 so that you can selectively enable some of them. 
 
 0:20:50.160,0:20:54.700
 For example, this is very good for 
-tracking down races in the sleeping queue.
+tracking down traces in the sleeping queue.
 
 0:20:54.700,0:21:01.700
 You can find referrals here. 
 
 0:21:02.770,0:21:04.820
-...
+
 
 0:21:04.820,0:21:06.220
 So, 
@@ -1332,7 +1328,7 @@ I think that actually our locking system
 is pretty complete, 
 
 0:21:21.750,0:21:26.919
-but it's also confusing for newcomers, 
+but it's also pretty confusing for newcomers, 
 it's not widely documented. 
 
 0:21:26.919,0:21:32.280
@@ -1361,14 +1357,14 @@ who just need to do simple tasks.
 For example, I saw a lot of guys coming from Linux World
 
 0:21:56.660,0:22:00.620
-who wanted to actually use spinlocks for time
+who wanted to actually use spinlocks for time.
 
 0:22:00.620,0:22:05.720
-it's obvious they are missing something from our
-architecture
+It's obvious they are missing something from our
+architecture.
 
 0:22:05.720,0:22:07.250
-From, uh, ...
+From
 
 0:22:07.250,0:22:11.010
 just a technical point of view,
@@ -1384,7 +1380,7 @@ we have lockmgr and sxlog
 
 0:22:22.900,0:22:27.990
 which are both read/write locks and 
-are both serverd by sleep queues. 
+are both servered by sleep queues. 
 
 0:22:27.990,0:22:31.800
 They have some differences, obviously, 
@@ -1394,21 +1390,20 @@ but, mainly,
 
 0:22:32.660,0:22:38.920
 we could manage the missing bits and 
-just one of the 2 interfaces. 
+just use one of the two interfaces. 
 
 0:22:38.920,0:22:42.059
-on the scene where he hasn't told you before
-visiting all
+
 
 0:22:42.059,0:22:43.920
 In the same way, as i told you before,
 
 0:22:43.920,0:22:47.340
-the sleeping point, true end sleep, 
+the sleeping point, true-end sleep, 
 read/write sleep and sxsleep 
 
 0:22:47.340,0:22:50.350
-should probably be merged with cond vars 
+should probably be managed with cond vars 
 
 0:22:50.350,0:22:52.930
 and superdoff our kernel 
@@ -1418,10 +1413,10 @@ and we should probably drop sema,
 
 0:22:55.070,0:23:00.290
 because it is obsolete, and can be 
-replaced by condova and mutex. 
+replaced by condvars and mutex. 
 
 0:23:00.290,0:23:02.620
-...
+
 
 0:23:02.620,0:23:03.830
 From
@@ -1500,7 +1495,7 @@ Instead, the other one
 
 0:24:10.290,0:24:16.180
 uses spinning on a local variable 
-which is not shared by the threads 
+which is not shared by the threads.
 
 0:24:16.180,0:24:18.030
 and the time spent 
@@ -1512,10 +1507,10 @@ on that
 local variable increases 
 
 0:24:22.780,0:24:25.440
-um...
+
 
 0:24:25.440,0:24:28.320
-...
+
 
 0:24:28.320,0:24:31.780
 with the passing of time.
@@ -1527,10 +1522,10 @@ Another interesting thing would be benchmarking
 different wake-up algorithms for blocking primitives.
 
 0:24:37.930,0:24:42.390
-We have an algorithms that has proven to be 
+We have an algorithm that has proven to be 
 
 0:24:42.390,0:24:42.910
-...
+
 
 0:24:42.910,0:24:45.200
 quite good 
@@ -1549,10 +1544,10 @@ a higher overhead but could give time improvements
 on a big SMP environment.
 
 0:24:59.760,0:25:02.500
-Um, ...
+
 
 0:25:02.500,0:25:07.000
-another thing that would be very interesting 
+Another thing that would be very interesting 
 to fix is the priority inversion problem
 
 0:25:07.000,0:25:08.670
@@ -1584,7 +1579,7 @@ is often just a single atomic operation,
 and
 
 0:25:30.010,0:25:33.770
-if it fails
+if it fails,
 
 0:25:33.770,0:25:36.900
 it falls down and the art pattern tries to do 
@@ -1595,7 +1590,7 @@ in this case the owner of record technic
 was going to make the fastpack too simple
 
 0:25:40.210,0:25:42.640
-Basically 
+Basically,
 
 0:25:42.640,0:25:46.310
 it just considers 
@@ -1611,7 +1606,7 @@ And it practically lands the priority to this
 owner of record which does it's right log. 
 
 0:26:02.210,0:26:06.900
-...
+
 
 0:26:06.900,0:26:11.900
 Another important thing obviously is improving locking
@@ -1647,4 +1642,4 @@ like the one we saw before with the malloc command,
 that needs to sleep.
 
 0:26:44.070,0:26:44.320
-Questions?
+Any questions?