COMP 3000 Essay 2 2010 Question 5 - Revision history

Soma: Protected "COMP 3000 Essay 2 2010 Question 5" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-12-03T19:44:44Z

Protected "COMP 3000 Essay 2 2010 Question 5" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 19:44, 3 December 2010
(No difference)

J powers: /* Why is it any better than what came before? */

2010-12-03T12:44:55Z

Why is it any better than what came before?

← Older revision		Revision as of 12:44, 3 December 2010
Line 76:		Line 76:
	Flaws common to both system updates and hot patches are that they are very difficult to properly develop, slow to implement, and result in potentially unsafe ad hoc solutions that are not scalable.		Flaws common to both system updates and hot patches are that they are very difficult to properly develop, slow to implement, and result in potentially unsafe ad hoc solutions that are not scalable.

	Conversely, LOOM is easy to use, fast to implement, highly flexible, scalable, and safe to use		Conversely, LOOM is easy to use, fast to implement, highly flexible, scalable, and safe to use.

	==Critique==		==Critique==

Nlessard at 04:29, 3 December 2010

2010-12-03T04:29:49Z

← Older revision		Revision as of 04:29, 3 December 2010
Line 102:		Line 102:
	[5] Tanenbaum, A. S. Modern Operating Systems (3rd Edition), page 128, 2008. Print.		[5] Tanenbaum, A. S. Modern Operating Systems (3rd Edition), page 128, 2008. Print.

	[6] "QUIESCE Function." 'IBM' IBM Corporation, 2008. Web. Accessed: Dec 2nd 2010. [http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.hcpb4/hcse5b21270.htm <http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.hcpb4/hcse5b21270.htm>]		[6] "QUIESCE Function." ''IBM'' IBM Corporation, 2008. Web. Accessed: Dec 2nd 2010. [http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.hcpb4/hcse5b21270.htm <http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.hcpb4/hcse5b21270.htm>]

	[7] Lu, Shan; Park, Soyeon; Seo, Eunsoo; Zhou, Yuanyuan. "Learning from Mistakes — A Comprehensive Study on Real World Concurrency Bug Characteristics". '' CiteSeerX ''. Dept. of Comp. Sci. at Univ. of Illinois, 2008. Web. Accessed Dec 2nd 2010. [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.121.1203 <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.121.1203>]		[7] Lu, Shan; Park, Soyeon; Seo, Eunsoo; Zhou, Yuanyuan. "Learning from Mistakes — A Comprehensive Study on Real World Concurrency Bug Characteristics". '' CiteSeerX ''. Dept. of Comp. Sci. at Univ. of Illinois, 2008. Web. Accessed Dec 2nd 2010. [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.121.1203 <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.121.1203>]

Nlessard at 04:24, 3 December 2010

2010-12-03T04:24:48Z

← Older revision		Revision as of 04:24, 3 December 2010
Line 21:		Line 21:
	'''Evacuation''' An algorithm for proactively pausing (and potentially changing) a state of code that will likely lead to a Race condition. One ''evacuates'' code from an unsafe location in memory so that one can install an execution filter there and prevent a race condition. Code is ''evacuated'' by either pausing it before it enters ab area or allowing it to quickly leave if it is already there.		'''Evacuation''' An algorithm for proactively pausing (and potentially changing) a state of code that will likely lead to a Race condition. One ''evacuates'' code from an unsafe location in memory so that one can install an execution filter there and prevent a race condition. Code is ''evacuated'' by either pausing it before it enters ab area or allowing it to quickly leave if it is already there.

	'''Execution Filters:''' Otherwise known as request filtering. ~~Request filters~~ allow you to inspect ~~the~~ request before and after ~~the main~~ logic is executed. ~~These are mutual exclusion filters~~ in ~~the context~~ of ~~this paper~~.		'''Execution Filters:''' Otherwise known as request filtering. Execution Filters allow you inspect a request to use a block of data before and after any logic is executed on it. You can, in effect, filter what runs when, perhaps pausing one piece of code while another works on an area, preventing a race condition.

	'''Function Quiescence''' The process of pausing and altering states, in order to avoid race conditions and overlapping between code segments.		'''Function Quiescence''' The process of pausing and altering states, in order to avoid race conditions and overlapping between code segments.

Nlessard at 04:17, 3 December 2010

2010-12-03T04:17:00Z

← Older revision		Revision as of 04:17, 3 December 2010
Line 19:		Line 19:
	'''Deadlock:''' Deadlocks usually occur within the context of two threads. One thread tries to lock a variable that the other thread has already locked and vice versa. The result of this is that each thread is waiting for each other's thread to release the variable. Thus a deadlock occurs and nothing can happen.		'''Deadlock:''' Deadlocks usually occur within the context of two threads. One thread tries to lock a variable that the other thread has already locked and vice versa. The result of this is that each thread is waiting for each other's thread to release the variable. Thus a deadlock occurs and nothing can happen.

	'''Evacuation''' ~~The process of~~ proactively pausing and changing ~~states~~ of code ~~sections~~ so that ~~those sections~~ can ~~be filtered for proper processing~~		'''Evacuation''' An algorithm for proactively pausing (and potentially changing) a state of code that will likely lead to a Race condition. One ''evacuates'' code from an unsafe location in memory so that one can install an execution filter there and prevent a race condition. Code is ''evacuated'' by either pausing it before it enters ab area or allowing it to quickly leave if it is already there.

	'''Execution Filters:''' Otherwise known as request filtering. Request filters allow you to inspect the request before and after the main logic is executed. These are mutual exclusion filters in the context of this paper.		'''Execution Filters:''' Otherwise known as request filtering. Request filters allow you to inspect the request before and after the main logic is executed. These are mutual exclusion filters in the context of this paper.

Dustinmartin: /* Good */

2010-12-03T02:28:01Z

Good

← Older revision		Revision as of 02:28, 3 December 2010
Line 83:		Line 83:

	The essay flows well and the information is delivered in a well put together order, allowing the reader to learn enough about LOOM (or any of the sub-topics involved in the explanation) before being informed about the next relative subject. The conclusion summarizes the paper in a clear and concise manner.		The essay flows well and the information is delivered in a well put together order, allowing the reader to learn enough about LOOM (or any of the sub-topics involved in the explanation) before being informed about the next relative subject. The conclusion summarizes the paper in a clear and concise manner.

			In terms of the technology that this paper serves to introduce, the offering is very strong. The authors make aggressive assertions stating the strengths of LOOM and back these assertions with unequivocal results through extensive testing. Specifically, the assertions made are that LOOM can dynamically locate and correct areas which may be susceptible to race conditions on live systems in real time, in a scalable, flexible, easy to use, safe to use, and fast to implement manor. The testing presented to support these assertions were nine real world race conditions of which each was successfully located and corrected, with little overhead.

	===Not-So-Good===		===Not-So-Good===

Dlangloi at 02:18, 3 December 2010

2010-12-03T02:18:22Z

← Older revision		Revision as of 02:18, 3 December 2010
Line 11:		Line 11:
	A race condition is a system flaw that “occurs when two threads access a shared variable at the same time." Race conditions can be very complex, time consuming and expensive to fix. Unfortunately, the most challenging part of race condition is not fixing it, but rather finding it. Race conditions are notorious for being extremely difficult to find, isolate and recreate. To help ease this process, the authors of this paper, Jingyue Wu, Heming Cui, Junfeng Yang, propose the adoption of LOOM.		A race condition is a system flaw that “occurs when two threads access a shared variable at the same time." Race conditions can be very complex, time consuming and expensive to fix. Unfortunately, the most challenging part of race condition is not fixing it, but rather finding it. Race conditions are notorious for being extremely difficult to find, isolate and recreate. To help ease this process, the authors of this paper, Jingyue Wu, Heming Cui, Junfeng Yang, propose the adoption of LOOM.

	LOOM is a system which dynamically locates ~~and corrects~~ areas which may be susceptible to race condition errors. The power of LOOM rests in its ability to operate on live applications in real time. This is possible thanks to its evacuation algorithm which injects execution filters to fix race conditions at runtime. Execution filters, otherwise known as request filtering, allow you to inspect the request before and after the main logic is executed. By leveraging execution filters as the means for correcting race conditions, LOOM is able to operate with very little performance overhead and is a highly scalable as the number of application threads increases.		LOOM is a system which dynamically locates areas which may be susceptible to race condition errors and allows the race condition to be potentially fixed. The power of LOOM rests in its ability to operate on live applications in real time. This is possible thanks to its evacuation algorithm which injects execution filters to fix race conditions at runtime. Execution filters, otherwise known as request filtering, allow you to inspect the request before and after the main logic is executed. By leveraging execution filters as the means for correcting race conditions, LOOM is able to operate with very little performance overhead and is a highly scalable as the number of application threads increases.

	The authors tested LOOM on existing real world race conditions found in common applications. The tests found that all tested race conditions were solved, with little performance overhead, in a scalable and easy to implement manner.		The authors tested LOOM on existing real world race conditions found in common applications. The tests found that all tested race conditions were solved, with little performance overhead, in a scalable and easy to implement manner.

Dlangloi at 02:14, 3 December 2010

2010-12-03T02:14:36Z

← Older revision		Revision as of 02:14, 3 December 2010
Line 29:		Line 29:
	'''Hybrid Instrumentation Engine:''' "Instrumentation refers to an ability to monitor or measure the level of a product's performance, to diagnose errors and writing trace information." [[#References \| [2]]] Instrument programs can have low runtime overhead, but instrumentation has to be done at compile time. Dynamic instrumentation can update programs at runtime but incur high overhead. A hybrid instrumentation is an implementation of combined static and dynamic instrumentation.		'''Hybrid Instrumentation Engine:''' "Instrumentation refers to an ability to monitor or measure the level of a product's performance, to diagnose errors and writing trace information." [[#References \| [2]]] Instrument programs can have low runtime overhead, but instrumentation has to be done at compile time. Dynamic instrumentation can update programs at runtime but incur high overhead. A hybrid instrumentation is an implementation of combined static and dynamic instrumentation.

	'''Lock:''' A lock is a way of limiting access to a common resource when using multiple threads. Lock and unlock methods are usually called at the beginning and end of a target method, respectively. "Mutual exclusion locks (mutexes) are a common method of serializing thread execution. Mutual exclusion locks synchronize threads, usually by ensuring that only one thread at a time executes a critical section of code. Mutex locks can also preserve single-threaded code." [[#References \| [3]]]		'''Lock:''' A lock is a way of limiting access to a common resource when using multiple threads. Lock and unlock methods are usually called at the beginning and end of a target method, respectively. It simply denies access when it is locked, and allows access when not locked. "Mutual exclusion locks (mutexes) are a common method of serializing thread execution. Mutual exclusion locks synchronize threads, usually by ensuring that only one thread at a time executes a critical section of code. Mutex locks can also preserve single-threaded code." [[#References \| [3]]]

	'''Mutex:''' Mutex (Mutual Exclusion) is an algorithm which prevents race conditions on a resource. Essentially, it forces any threads that are trying to access the resource to wait until the current thread accessing the resource has completed using it.		'''Mutex:''' Mutex (Mutual Exclusion) is an algorithm which prevents race conditions on a resource. Essentially, it forces any threads that are trying to access the resource to wait until the current thread accessing the resource has completed using it.

Dlangloi at 02:11, 3 December 2010

2010-12-03T02:11:28Z

← Older revision		Revision as of 02:11, 3 December 2010
Line 31:		Line 31:
	'''Lock:''' A lock is a way of limiting access to a common resource when using multiple threads. Lock and unlock methods are usually called at the beginning and end of a target method, respectively. "Mutual exclusion locks (mutexes) are a common method of serializing thread execution. Mutual exclusion locks synchronize threads, usually by ensuring that only one thread at a time executes a critical section of code. Mutex locks can also preserve single-threaded code." [[#References \| [3]]]		'''Lock:''' A lock is a way of limiting access to a common resource when using multiple threads. Lock and unlock methods are usually called at the beginning and end of a target method, respectively. "Mutual exclusion locks (mutexes) are a common method of serializing thread execution. Mutual exclusion locks synchronize threads, usually by ensuring that only one thread at a time executes a critical section of code. Mutex locks can also preserve single-threaded code." [[#References \| [3]]]

	'''Mutex:''' ~~Unable~~ to ~~be both true at~~ the ~~same time~~.		'''Mutex:''' Mutex (Mutual Exclusion) is an algorithm which prevents race conditions on a resource. Essentially, it forces any threads that are trying to access the resource to wait until the current thread accessing the resource has completed using it.

	'''Race Condition:''' "A race condition occurs when two threads access a shared variable at the same time." [[#References \| [4]]]		'''Race Condition:''' "A race condition occurs when two threads access a shared variable at the same time." [[#References \| [4]]]

Dustinmartin: /* Problem being addressed */

2010-12-02T21:20:08Z

Problem being addressed

← Older revision		Revision as of 21:20, 2 December 2010
Line 40:		Line 40:
	===Problem being addressed===		===Problem being addressed===

	With the rise of multiple core systems, multi-threaded programs are often prone to race conditions. Races are hard to detect, test and debug. Many systems are designed to detect, reproduce and diagnose race conditions, but these do not directly address the actual race. This is normally dealt with via a software update which would often require a software restart and potentially introduces new bugs.[[#References \| [7]]] Patches require you to be aware of the cause of the problem, and take time to produce, test, and install, leaving a potential user of the software waiting, potentially for months. Due to the immaturity of current race detectors, this paper explains a new approach to race detection and workarounds through the use of LOOM. The ~~Goal~~ being to quickly address the actual symptom, the race condition, ~~as opposed~~ to the cause, an unknown bug in the software, ~~allowing~~ the system to keep running without a software update or a reset.		With the rise of multiple core systems, multi-threaded programs are often prone to race conditions. Races are hard to detect, test and debug. Many systems are designed to detect, reproduce and diagnose race conditions, but these do not directly address the actual race. This is normally dealt with via a software update which would often require a software restart and potentially introduces new bugs.[[#References \| [7]]] Patches require you to be aware of the cause of the problem, and take time to produce, test, and install, leaving a potential user of the software waiting, potentially for months. Due to the immaturity of current race detectors, this paper explains a new approach to race detection and workarounds through the use of LOOM. The goal being to quickly address the actual symptom, the race condition, in real time on live systems. This is in opposition to the conventional approach which focuses on the cause of the race condition, an unknown bug in the software. By targeting the race condition itself, the system is able to keep running without a software update or even a reset.

	===Related work===		===Related work===