Changeset fc96890 for doc/theses/thierry_delisle_PhD/thesis/text/practice.tex

Timestamp:

Sep 13, 2022, 3:07:25 PM (22 months ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, master, pthread-emulation

Children:

3606fe4

Parents:

1c334d1

Message:

Ran second spell/grammar checker and now the cows have come home

File:

• doc/theses/thierry_delisle_PhD/thesis/text/practice.tex (modified) (4 diffs)

doc/theses/thierry_delisle_PhD/thesis/text/practice.tex

@@ -55 +55 @@
 A simpler approach is to use a \newterm{Readers-Writer Lock}~\cite{wiki:rwlock}, where the resizing requires acquiring the lock as a writer while simply enqueueing/dequeuing \ats requires acquiring the lock as a reader.
 Using a Readers-Writer lock solves the problem of dynamically resizing and leaves the challenge of finding or building a lock with sufficient good read-side performance.
-Since this approach is not a very complex challenge and an ad-hoc solution is perfectly acceptable, building a Readers-Writer lock was the path taken.
+Since this approach is not a very complex challenge and an ad hoc solution is perfectly acceptable, building a Readers-Writer lock was the path taken.
 
 To maximize reader scalability, readers should not contend with each other when attempting to acquire and release a critical section.
@@ -61 +61 @@
 The read-acquire possibly waits for a writer to finish the critical section and then acquires a reader's local spinlock.
 The writer acquires the global lock, guaranteeing mutual exclusion among writers, and then acquires each of the local reader locks.
-Acquiring all the local read locks guarantees mutual exclusion among the readers and the writer, while the wait on the read side prevents readers from continuously starving the writer.
+Acquiring all the local read-locks guarantees mutual exclusion among the readers and the writer, while the wait on the read side prevents readers from continuously starving the writer.
 Figure~\ref{f:SpecializedReadersWriterLock} shows the outline for this specialized readers-writer lock.
 The lock in nonblocking, so both readers and writers spin while the lock is held.
@@ -113 +113 @@
 Therefore, the \CFA scheduler simply follows the ``Race-to-Idle''~\cite{Albers12} approach where a sleeping \proc is woken any time a \at becomes ready and \procs go to idle sleep anytime they run out of work.
 
-An interesting sub-part of this heuristic is what to do with bursts of \ats that become ready.
+An interesting subpart of this heuristic is what to do with bursts of \ats that become ready.
 Since waking up a sleeping \proc can have notable latency, multiple \ats may become ready while a single \proc is waking up.
 This fact begs the question, if many \procs are available, how many should be woken?
 If the ready \ats will run longer than the wake-up latency, waking one \proc per \at will offer maximum parallelization.
-If the ready \ats will run for a short very short time, waking many \procs may be wasteful.
+If the ready \ats will run for a very short time, waking many \procs may be wasteful.
 As mentioned, a heuristic to handle these complex cases is outside the scope of this thesis, the behaviour of the scheduler in this particular case is left unspecified.
 
@@ -173 +173 @@
 
 This approach also simplifies notification.
-Indeed, \procs not only need to be notified when a new \at is readied, but also must be notified during manual resizing, so the \gls{kthrd} can be joined.
+Indeed, \procs not only need to be notified when a new \at is readied, but must also be notified during manual resizing, so the \gls{kthrd} can be joined.
 These requirements mean whichever entity removes idle \procs from the sleeper list must be able to do so in any order.
 Using a simple lock over this data structure makes the removal much simpler than using a lock-free data structure.