https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2014F%3A_Assignment_5 2026-06-02T22:28:20Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19566&oldid=prev 2014-12-11T18:58:43Z

<p><span dir="auto"><span class="autocomment">Solutions</span></span></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 18:58, 11 December 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l25">Line 25:</td> <td colspan="2" class="diff-lineno">Line 25:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># Peterson&#039;s algorithm assumes that writes to main memory by one processor are immediately visible to other processors.  On modern systems, however, writes are first made to caches (L1, L2, L3) before they are propagated to RAM.  While RAM is updated continuously, there is a small window of time when values in memory are stale relative to those in cache.  When those caches are processor/core specific (as L1 and L2 generally are), there is a window of opportunity for inconsistency that causes Peterson&#039;s algorithm to be incorrect.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># Peterson&#039;s algorithm assumes that writes to main memory by one processor are immediately visible to other processors.  On modern systems, however, writes are first made to caches (L1, L2, L3) before they are propagated to RAM.  While RAM is updated continuously, there is a small window of time when values in memory are stale relative to those in cache.  When those caches are processor/core specific (as L1 and L2 generally are), there is a window of opportunity for inconsistency that causes Peterson&#039;s algorithm to be incorrect.</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># High performance multitheaded code will sometimes use spinlocks when the expected time of contention - the time in the critical section - is smaller than the amount of time required to put a thread to sleep and wake it up.  Switching contexts, changing process states - steps such as these take time to perform.  That time is overhead that can reduce scalability for locks that are held only very briefly.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># High performance multitheaded code will sometimes use spinlocks when the expected time of contention - the time in the critical section - is smaller than the amount of time required to put a thread to sleep and wake it up.  Switching contexts, changing process states - steps such as these take time to perform.  That time is overhead that can reduce scalability for locks that are held only very briefly.</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del style="font-weight: bold; text-decoration: none;">#</del></div></td><td colspan="2" class="diff-side-added"></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19425&oldid=prev 2014-10-19T19:47:48Z

<p><span dir="auto"><span class="autocomment">Solutions</span></span></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 19:47, 19 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l24">Line 24:</td> <td colspan="2" class="diff-lineno">Line 24:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># Peterson&#039;s algorithm assumes that writes to main memory by one processor are immediately visible to other processors.  On modern systems, however, writes are first made to caches (L1, L2, L3) before they are propagated to RAM.  While RAM is updated continuously, there is a small window of time when values in memory are stale relative to those in cache.  When those caches are processor/core specific (as L1 and L2 generally are), there is a window of opportunity for inconsistency that causes Peterson&#039;s algorithm to be incorrect.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># Peterson&#039;s algorithm assumes that writes to main memory by one processor are immediately visible to other processors.  On modern systems, however, writes are first made to caches (L1, L2, L3) before they are propagated to RAM.  While RAM is updated continuously, there is a small window of time when values in memory are stale relative to those in cache.  When those caches are processor/core specific (as L1 and L2 generally are), there is a window of opportunity for inconsistency that causes Peterson&#039;s algorithm to be incorrect.</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># <ins style="font-weight: bold; text-decoration: none;">High performance multitheaded code will sometimes use spinlocks when the expected time of contention - the time in the critical section - is smaller than the amount of time required to put a thread to sleep and wake it up.  Switching contexts, changing process states - steps such as these take time to perform.  That time is overhead that can reduce scalability for locks that are held only very briefly.</ins></div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19424&oldid=prev 2014-10-19T19:16:49Z

<p></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 19:16, 19 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l23">Line 23:</td> <td colspan="2" class="diff-lineno">Line 23:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The largest page size would be 16K because the 14 low order bits are are the same, and 2^14 = 16,384 = 16K.  The low order bits make up the page offset which is always the same between a virtual address and its mapping to a physical address.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The largest page size would be 16K because the 14 low order bits are are the same, and 2^14 = 16,384 = 16K.  The low order bits make up the page offset which is always the same between a virtual address and its mapping to a physical address.</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># <ins style="font-weight: bold; text-decoration: none;">Peterson's algorithm assumes that writes to main memory by one processor are immediately visible to other processors.  On modern systems, however, writes are first made to caches (L1, L2, L3) before they are propagated to RAM.  While RAM is updated continuously, there is a small window of time when values in memory are stale relative to those in cache.  When those caches are processor/core specific (as L1 and L2 generally are), there is a window of opportunity for inconsistency that causes Peterson's algorithm to be incorrect.</ins></div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19423&oldid=prev 2014-10-19T19:01:04Z

<p></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 19:01, 19 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l21">Line 21:</td> <td colspan="2" class="diff-lineno">Line 21:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># While there are hybrid segmentation/paging schemes where segment registers hold physical addresses, in most systems (including the x86 is full 32-bit and 64-bit modes with virtual memory enabled), segment registers hold virtual addresses.  They have to because segments must consist of contiguous memory, and in a paging system memory a process&#039;s memory, is, by design, not contiguous - it uses whatever physical memory (frames) that are handy.  These frames are stitched together by the virtual memory hardware into the contiguous regions needed to support segments.  For more information on segments on x86, see [http://en.wikipedia.org/wiki/X86_memory_segmentation the Wikipedia article on x86 segmentation].</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># While there are hybrid segmentation/paging schemes where segment registers hold physical addresses, in most systems (including the x86 is full 32-bit and 64-bit modes with virtual memory enabled), segment registers hold virtual addresses.  They have to because segments must consist of contiguous memory, and in a paging system memory a process&#039;s memory, is, by design, not contiguous - it uses whatever physical memory (frames) that are handy.  These frames are stitched together by the virtual memory hardware into the contiguous regions needed to support segments.  For more information on segments on x86, see [http://en.wikipedia.org/wiki/X86_memory_segmentation the Wikipedia article on x86 segmentation].</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The stack segment register SS and the data segment register DS can overlap.  In fact, in modern x86 programming the segment registers - including SS and DS - are set to the entire memory address range: their base is 0 and their bound it the top of memory (2^32-1 or 2^64-1), thus effectively making them do nothing.  &#039;&#039;&#039;NOTE:&#039;&#039;&#039; The parenthetical clarification is WRONG.  It makes no sense.  %esp and %ebp are registers for the current frame.  They have nothing to do with segmentation.  See the [http://en.wikipedia.org/wiki/Call_stack Wikipedia article on the call stack].</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The stack segment register SS and the data segment register DS can overlap.  In fact, in modern x86 programming the segment registers - including SS and DS - are set to the entire memory address range: their base is 0 and their bound it the top of memory (2^32-1 or 2^64-1), thus effectively making them do nothing.  &#039;&#039;&#039;NOTE:&#039;&#039;&#039; The parenthetical clarification is WRONG.  It makes no sense.  %esp and %ebp are registers for the current frame.  They have nothing to do with segmentation.  See the [http://en.wikipedia.org/wiki/Call_stack Wikipedia article on the call stack].</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># <ins style="font-weight: bold; text-decoration: none;">The largest page size would be 16K because the 14 low order bits are are the same, and 2^14 = 16,384 = 16K.  The low order bits make up the page offset which is always the same between a virtual address and its mapping to a physical address.</ins></div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19419&oldid=prev 2014-10-18T03:18:58Z

<p></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 03:18, 18 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l19">Line 19:</td> <td colspan="2" class="diff-lineno">Line 19:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>==Solutions==</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>==Solutions==</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># On 32-bit processors with PAE, pointers for regular C programs (running in userspace) are 32 bits because the size of the virtual address space is the same as before.  PAE extends just the physical address space.  The advantage of this is only the kernel needs to be modified to use the additional RAM.  The disadvantage is all regular programs can address at most 4 GiB of memory.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># On 32-bit processors with PAE, pointers for regular C programs (running in userspace) are 32 bits because the size of the virtual address space is the same as before.  PAE extends just the physical address space.  The advantage of this is only the kernel needs to be modified to use the additional RAM.  The disadvantage is all regular programs can address at most 4 GiB of memory.</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div># While there are hybrid segmentation/paging schemes where segment registers hold physical addresses, in most systems (including the x86 is full 32-bit and 64-bit modes with virtual memory enabled), segment registers hold virtual addresses.  They have to because segments must consist of contiguous memory, and in a paging system memory a process's memory, is, by design, not contiguous - it uses whatever physical memory (frames) that are handy.  These frames are stitched together by the virtual memory hardware into the contiguous regions needed to support segments.  For more information on segments on x86, see [http://en.wikipedia.org/wiki/X86_memory_segmentation the Wikipedia article on x86 segmentation].  '''NOTE:''' %esp and %ebp are registers for the current frame.  They have nothing to do with segmentation<del style="font-weight: bold; text-decoration: none;">; in fact in modern x86 programming the segment registers are (almost) all set to cover the entire address space, thus effectively making them do nothing</del>.  See the [http://en.wikipedia.org/wiki/Call_stack Wikipedia article on the call stack].</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># While there are hybrid segmentation/paging schemes where segment registers hold physical addresses, in most systems (including the x86 is full 32-bit and 64-bit modes with virtual memory enabled), segment registers hold virtual addresses.  They have to because segments must consist of contiguous memory, and in a paging system memory a process's memory, is, by design, not contiguous - it uses whatever physical memory (frames) that are handy.  These frames are stitched together by the virtual memory hardware into the contiguous regions needed to support segments.  For more information on segments on x86, see [http://en.wikipedia.org/wiki/X86_memory_segmentation the Wikipedia article on x86 segmentation]<ins style="font-weight: bold; text-decoration: none;">.</ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"># The stack segment register SS and the data segment register DS can overlap.  In fact, in modern x86 programming the segment registers - including SS and DS - are set to the entire memory address range: their base is 0 and their bound it the top of memory (2^32-1 or 2^64-1), thus effectively making them do nothing</ins>.  '''NOTE:''' <ins style="font-weight: bold; text-decoration: none;">The parenthetical clarification is WRONG.  It makes no sense.  </ins>%esp and %ebp are registers for the current frame.  They have nothing to do with segmentation.  See the [http://en.wikipedia.org/wiki/Call_stack Wikipedia article on the call stack].</div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">#</ins></div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19418&oldid=prev 2014-10-18T03:11:10Z

<p></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 03:11, 18 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l19">Line 19:</td> <td colspan="2" class="diff-lineno">Line 19:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>==Solutions==</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>==Solutions==</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># On 32-bit processors with PAE, pointers for regular C programs (running in userspace) are 32 bits because the size of the virtual address space is the same as before.  PAE extends just the physical address space.  The advantage of this is only the kernel needs to be modified to use the additional RAM.  The disadvantage is all regular programs can address at most 4 GiB of memory.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># On 32-bit processors with PAE, pointers for regular C programs (running in userspace) are 32 bits because the size of the virtual address space is the same as before.  PAE extends just the physical address space.  The advantage of this is only the kernel needs to be modified to use the additional RAM.  The disadvantage is all regular programs can address at most 4 GiB of memory.</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div># While there are hybrid segmentation/paging schemes where segment registers hold physical addresses, in most systems (including the x86 is full 32-bit and 64-bit modes with virtual memory enabled), segment registers hold virtual addresses.  They have to because segments must consist of contiguous memory, and in a paging system memory a process's memory, is, by design, not contiguous - it uses whatever physical memory (frames) that are handy.  These frames are stitched together by the virtual memory hardware into the contiguous regions needed to support segments.  For more information on segments on x86, see [http://en.wikipedia.org/wiki/X86_memory_segmentation the Wikipedia article on x86 segmentation].  '''NOTE:''' %esp and %ebp are registers for the current frame.  They have nothing to do with segmentation; in fact in modern x86 programming the segment registers are (almost) all set to cover the entire address space, thus effectively making them do nothing.  See the [http://en.wikipedia.org/wiki/Call_stack Wikipedia article on call stack].</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># While there are hybrid segmentation/paging schemes where segment registers hold physical addresses, in most systems (including the x86 is full 32-bit and 64-bit modes with virtual memory enabled), segment registers hold virtual addresses.  They have to because segments must consist of contiguous memory, and in a paging system memory a process's memory, is, by design, not contiguous - it uses whatever physical memory (frames) that are handy.  These frames are stitched together by the virtual memory hardware into the contiguous regions needed to support segments.  For more information on segments on x86, see [http://en.wikipedia.org/wiki/X86_memory_segmentation the Wikipedia article on x86 segmentation].  '''NOTE:''' %esp and %ebp are registers for the current frame.  They have nothing to do with segmentation; in fact in modern x86 programming the segment registers are (almost) all set to cover the entire address space, thus effectively making them do nothing.  See the [http://en.wikipedia.org/wiki/Call_stack Wikipedia article on <ins style="font-weight: bold; text-decoration: none;">the </ins>call stack].</div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"># The xchg x86 instruction swaps two values.  If both values are stored in memory, this swap is atomic.  xchg is very useful for implementing correct concurrency mechanisms such as mutexes because the swap is guaranteed to be atomic.</ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">#</ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">#</ins></div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>#</div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19417&oldid=prev 2014-10-18T03:07:29Z

<p></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 03:07, 18 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l16">Line 16:</td> <td colspan="2" class="diff-lineno">Line 16:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Spinlocks cause a program to loop infinitely until a resource becomes available.  High performance multi-threaded code often uses spinlocks rather than locks that yield the processor when waiting for the lock to become available.  When are spinlocks preferable?  Why?</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Spinlocks cause a program to loop infinitely until a resource becomes available.  High performance multi-threaded code often uses spinlocks rather than locks that yield the processor when waiting for the lock to become available.  When are spinlocks preferable?  Why?</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [3] Create &lt;tt&gt;dotprod_lockfree.c&lt;/tt&gt; by modifying [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c dotprod_mutex.c] (From this [https://computing.llnl.gov/tutorials/pthreads/ LLNL tutorial]) so that it does not do any locking using mutexes &#039;&#039;&#039;or any other explicit locking mechanism&#039;&#039;&#039;.  In other words, the program should still be multithreaded; the threads should be able to run without any race conditions corrupting the computation but without grabbing and releasing any locks (explicitly).  Explain why your modifications are correct.  (You may want to refer to the [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_serial.c serial version] to help you understand what the program is supposed to do.)</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [3] Create &lt;tt&gt;dotprod_lockfree.c&lt;/tt&gt; by modifying [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c dotprod_mutex.c] (From this [https://computing.llnl.gov/tutorials/pthreads/ LLNL tutorial]) so that it does not do any locking using mutexes &#039;&#039;&#039;or any other explicit locking mechanism&#039;&#039;&#039;.  In other words, the program should still be multithreaded; the threads should be able to run without any race conditions corrupting the computation but without grabbing and releasing any locks (explicitly).  Explain why your modifications are correct.  (You may want to refer to the [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_serial.c serial version] to help you understand what the program is supposed to do.)</div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">==Solutions==</ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"># On 32-bit processors with PAE, pointers for regular C programs (running in userspace) are 32 bits because the size of the virtual address space is the same as before.  PAE extends just the physical address space.  The advantage of this is only the kernel needs to be modified to use the additional RAM.  The disadvantage is all regular programs can address at most 4 GiB of memory.</ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"># While there are hybrid segmentation/paging schemes where segment registers hold physical addresses, in most systems (including the x86 is full 32-bit and 64-bit modes with virtual memory enabled), segment registers hold virtual addresses.  They have to because segments must consist of contiguous memory, and in a paging system memory a process's memory, is, by design, not contiguous - it uses whatever physical memory (frames) that are handy.  These frames are stitched together by the virtual memory hardware into the contiguous regions needed to support segments.  For more information on segments on x86, see [http://en.wikipedia.org/wiki/X86_memory_segmentation the Wikipedia article on x86 segmentation].  '''NOTE:''' %esp and %ebp are registers for the current frame.  They have nothing to do with segmentation; in fact in modern x86 programming the segment registers are (almost) all set to cover the entire address space, thus effectively making them do nothing.  See the [http://en.wikipedia.org/wiki/Call_stack Wikipedia article on call stack].</ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">#</ins></div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19410&oldid=prev 2014-10-15T18:42:04Z

<p><span dir="auto"><span class="autocomment">Questions</span></span></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 18:42, 15 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l10">Line 10:</td> <td colspan="2" class="diff-lineno">Line 10:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Some x86 processors have support for PAE (physical address extensions), which allows for the use of more than 4 GiB of memory with a 32-bit processor.  On a system with PAE, what is the size of pointers used in regular C programs?  Why?</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Some x86 processors have support for PAE (physical address extensions), which allows for the use of more than 4 GiB of memory with a 32-bit processor.  On a system with PAE, what is the size of pointers used in regular C programs?  Why?</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] On a system that supports both paging and segmentation (such as the x86 in 32-bit protected mode), do segment base registers hold physical or virtual addresses?  Explain why briefly.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] On a system that supports both paging and segmentation (such as the x86 in 32-bit protected mode), do segment base registers hold physical or virtual addresses?  Explain why briefly.</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div># [1] Do the stack and data segments on the x86 ever overlap?  Explain briefly.</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># [1] Do the stack and data segments on the x86 <ins style="font-weight: bold; text-decoration: none;">(as referred to by %esp and %ebp) </ins>ever overlap?  Explain briefly.</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] If we have a system where virtual address 0x52D2C3A3 mapped to physical address 0x13A103A3, what is the largest page size that could be used for this mapping?  Why?</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] If we have a system where virtual address 0x52D2C3A3 mapped to physical address 0x13A103A3, what is the largest page size that could be used for this mapping?  Why?</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] What is the &lt;tt&gt;xchg&lt;/tt&gt; x86 instruction do?  Why is it important for creating concurrent programs?</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] What is the &lt;tt&gt;xchg&lt;/tt&gt; x86 instruction do?  Why is it important for creating concurrent programs?</div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19409&oldid=prev 2014-10-15T18:28:21Z

<p><span dir="auto"><span class="autocomment">Questions</span></span></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 18:28, 15 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l15">Line 15:</td> <td colspan="2" class="diff-lineno">Line 15:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Peterson&#039;s algorithm does not reliably work on modern machines.  Explain why briefly by making reference to the memory hierarchy of modern systems (e.g., relationship between registers, caches, and main memory/RAM).</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Peterson&#039;s algorithm does not reliably work on modern machines.  Explain why briefly by making reference to the memory hierarchy of modern systems (e.g., relationship between registers, caches, and main memory/RAM).</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Spinlocks cause a program to loop infinitely until a resource becomes available.  High performance multi-threaded code often uses spinlocks rather than locks that yield the processor when waiting for the lock to become available.  When are spinlocks preferable?  Why?</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Spinlocks cause a program to loop infinitely until a resource becomes available.  High performance multi-threaded code often uses spinlocks rather than locks that yield the processor when waiting for the lock to become available.  When are spinlocks preferable?  Why?</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div># [3] Create &lt;tt&gt;dotprod_lockfree.c&lt;/tt&gt; by modifying [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c dotprod_mutex.c] (From this [https://computing.llnl.gov/tutorials/pthreads/ LLNL tutorial]) so that it does not do any locking using mutexes '''or any other explicit locking mechanism'''.  In other words, the program should still be multithreaded; the threads should be able to run without any race conditions corrupting the computation.  Explain why your modifications are correct.  (You may want to refer to the [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_serial.c serial version] to help you understand what the program is supposed to do.)</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># [3] Create &lt;tt&gt;dotprod_lockfree.c&lt;/tt&gt; by modifying [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c dotprod_mutex.c] (From this [https://computing.llnl.gov/tutorials/pthreads/ LLNL tutorial]) so that it does not do any locking using mutexes '''or any other explicit locking mechanism'''.  In other words, the program should still be multithreaded; the threads should be able to run without any race conditions corrupting the computation <ins style="font-weight: bold; text-decoration: none;">but without grabbing and releasing any locks (explicitly)</ins>.  Explain why your modifications are correct.  (You may want to refer to the [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_serial.c serial version] to help you understand what the program is supposed to do.)</div></td></tr> </table>

Soma https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2014F:_Assignment_5&diff=19408&oldid=prev 2014-10-15T18:27:48Z

<p><span dir="auto"><span class="autocomment">Questions</span></span></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 18:27, 15 October 2014</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l15">Line 15:</td> <td colspan="2" class="diff-lineno">Line 15:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Peterson&#039;s algorithm does not reliably work on modern machines.  Explain why briefly by making reference to the memory hierarchy of modern systems (e.g., relationship between registers, caches, and main memory/RAM).</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Peterson&#039;s algorithm does not reliably work on modern machines.  Explain why briefly by making reference to the memory hierarchy of modern systems (e.g., relationship between registers, caches, and main memory/RAM).</div></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Spinlocks cause a program to loop infinitely until a resource becomes available.  High performance multi-threaded code often uses spinlocks rather than locks that yield the processor when waiting for the lock to become available.  When are spinlocks preferable?  Why?</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div># [1] Spinlocks cause a program to loop infinitely until a resource becomes available.  High performance multi-threaded code often uses spinlocks rather than locks that yield the processor when waiting for the lock to become available.  When are spinlocks preferable?  Why?</div></td></tr> <tr><td class="diff-marker" data-marker="−"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div># [3] Create &lt;tt&gt;dotprod_lockfree.c&lt;/tt&gt; by modifying [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c dotprod_mutex.c] (From this [https://computing.llnl.gov/tutorials/pthreads/ LLNL tutorial]) so that it does not do any locking using mutexes.  In other words, the program should still be multithreaded; the threads should be able to run without any race conditions corrupting the computation.  Explain why your modifications are correct.  (You may want to refer to the [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_serial.c serial version] to help you understand what the program is supposed to do.)</div></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div># [3] Create &lt;tt&gt;dotprod_lockfree.c&lt;/tt&gt; by modifying [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c dotprod_mutex.c] (From this [https://computing.llnl.gov/tutorials/pthreads/ LLNL tutorial]) so that it does not do any locking using mutexes <ins style="font-weight: bold; text-decoration: none;">'''or any other explicit locking mechanism'''</ins>.  In other words, the program should still be multithreaded; the threads should be able to run without any race conditions corrupting the computation.  Explain why your modifications are correct.  (You may want to refer to the [https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_serial.c serial version] to help you understand what the program is supposed to do.)</div></td></tr> </table>

Soma