Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Solutions to Chapter 16 | Low Level<br />
16 8 A device boots with an empty FIFO queue In <strong>the</strong> first 400 ns period after startup,<br />
and in each subsequent 400 ns period, a maximum of 80 words will be written to <strong>the</strong><br />
queue Each write takes 4 ns A worker thread requires 3 ns to read a word, and 2 ns to<br />
process it before reading <strong>the</strong> next word What is <strong>the</strong> shortest depth of <strong>the</strong> FIFO such<br />
that no data is lost?<br />
SOLUTION<br />
2 4 5<br />
<strong>Cracking</strong> <strong>the</strong> <strong>Coding</strong> <strong>Interview</strong> | Knowledge Based<br />
pg 82<br />
While a perfectly optimal solution is complex, an interviewer is most interested in how you<br />
approach <strong>the</strong> problem<br />
THEORY<br />
First, note that writes do not have to be evenly distributed within a period Thus a likely worst<br />
case is 80 words are written at <strong>the</strong> end of <strong>the</strong> first period, followed by 80 more at <strong>the</strong> start of<br />
<strong>the</strong> next<br />
Note that <strong>the</strong> maximum write rate for a full period is exactly matched by a full period of processing<br />
(400 ns / ((3 ns + 2 ns)/process) = 80 processed words/period)<br />
As <strong>the</strong> 2nd period in our example is fully saturated, adding writes from a 3rd period would<br />
not add additional stress, and this example is a true worst case for <strong>the</strong> conditions<br />
A SAFE QUEUE DEPTH<br />
For an estimate of maximum queue size, notice that <strong>the</strong>se 160 writes take 640 ns (160 writes<br />
* 4 ns / write = 640 ns), during which time only 128 words have been read (640 ns / ((3 ns + 2<br />
ns) / word) = 128 words) However, <strong>the</strong> first read cannot start until <strong>the</strong> first write has finished,<br />
which fills an extra slot in <strong>the</strong> queue<br />
Also, depending on <strong>the</strong> interactions between read and write timing, a second additional slot<br />
may be necessary to ensure a write does not trash <strong>the</strong> contents of a concurrently occurring<br />
read Thus, a safe estimate is that <strong>the</strong> queue must be at least 34 words deep (160 - 128 + 1 +<br />
1 = 34) to accommodate <strong>the</strong> unread words<br />
FINDING AN OPTIMAL (MINIMAL) QUEUE DEPTH<br />
Depending on <strong>the</strong> specifics of <strong>the</strong> problem, it’s possible that <strong>the</strong> final queue spot could be<br />
safely removed In many cases, <strong>the</strong> time required to do an edge case analysis to determine<br />
safety is not worth <strong>the</strong> effort However, if <strong>the</strong> interviewer is interested, <strong>the</strong> full analysis follows<br />
We are interested in <strong>the</strong> exact queue load during <strong>the</strong> final (160th) consecutive write to <strong>the</strong><br />
queue We can approach this by graphing <strong>the</strong> queue load from time = 0 ns, observing <strong>the</strong><br />
pattern, and extending it to time = 716 ns, <strong>the</strong> time of <strong>the</strong> final consecutive write<br />
The graph below shows that <strong>the</strong> queue load increases as each write begins, and decreases