COMP 3000 Essay 2 2010 Question 7 - Revision history

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

2010-12-03T19:45:04Z

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

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

Cha0s: /* Conclusion */

2010-12-03T11:37:24Z

Conclusion

← Older revision		Revision as of 11:37, 3 December 2010
Line 131:		Line 131:
	The paper's extensive examination of the previously unstudied ad hoc synchronizations concludes that: they are prevalent in today's concurrent software, they are problematic, and they should be avoided. The basis of their study is well supported with diverse programs, but could always have used more.		The paper's extensive examination of the previously unstudied ad hoc synchronizations concludes that: they are prevalent in today's concurrent software, they are problematic, and they should be avoided. The basis of their study is well supported with diverse programs, but could always have used more.

	Despite the fact that it used a relatively small amount of applications as the basis for the study, the fact that it was able to detect ad hoc synchronizations in software they had not previously analyzed is very impressive. Remarkable still is that it uncovered several major bugs in popular applications that had previously gone undiscovered. The fact that ad hoc synchronizations are fairly sparse (86 being the most they found), the false positive rate is acceptable, as it only means the manual analysis of a few dozen loops at most. The static approach allows the analysis of the entire code base~~, and with~~ a success rate of 96%, the possible loss of precision is acceptable.		Despite the fact that it used a relatively small amount of applications as the basis for the study, the fact that it was able to detect ad hoc synchronizations in software they had not previously analyzed is very impressive. Remarkable still is that it uncovered several major bugs in popular applications that had previously gone undiscovered. The fact that ad hoc synchronizations are fairly sparse (86 being the most they found), means that the false positive rate is acceptable, as it only means the manual analysis of a few dozen loops at most. The static approach (as opposed to dynamic) allows the analysis of the entire code base. With a success rate of 96%, the possible loss of precision is acceptable.

	Overall, both the study regarding the harm of ad hoc synchronizations and the way in which they are detected has been enlightening. It shows both the practices involved in specialized debugging tools, as well as the importance of standardized approaches to concurrency.		Overall, both the study regarding the harm of ad hoc synchronizations and the way in which they are detected has been enlightening. It shows both the practices involved in specialized debugging tools, as well as the importance of standardized approaches to concurrency.

Cha0s: /* Critique */

2010-12-03T11:35:41Z

Critique

← Older revision		Revision as of 11:35, 3 December 2010
Line 121:		Line 121:

	===Evaluation===		===Evaluation===

	The authors of the paper chose a mix of the leading concurrent open-source software programs<sup>[[#Foot10\|10]]</sup> to base their study on. They were chosen to represent different uses of applications for server, desktop and scientific applications. The number of ad hoc synchronizations were determined by two authors who reviewed the source code themselves. They were both experienced with the code base, but mistakes could have been made. General conclusions would be hard to draw from the limited data set, but the study gives strong indicators of ad hoc synchronizations characteristics and their effects based on evidence from the software tested.		The authors of the paper chose a mix of the leading concurrent open-source software programs<sup>[[#Foot10\|10]]</sup> to base their study on. They were chosen to represent different uses of applications for server, desktop and scientific applications. The number of ad hoc synchronizations were determined by two authors who reviewed the source code themselves. They were both experienced with the code base, but mistakes could have been made. General conclusions would be hard to draw from the limited data set, but the study gives strong indicators of ad hoc synchronizations characteristics and their effects based on evidence from the software tested.

	~~SynchFinder, the tool that the authors created~~ has the ~~benefit~~ of a high ~~degree of~~ success, on average finding 96% of ad hoc synchronizations ~~and~~ can be ~~extended~~ to other ~~data race and bad practice detector~~ tools ~~such as reducing~~ Valgrind data race checker's false positives by 43%-86%~~. SynchFinder fills a niche where other tools have failed to detect ad hoc synchronizations before~~. On the downside SynchFinder produces 6% false positives. ~~The~~ false positives ~~are~~ due to lack of source code on library functions and incorrect pointer ~~alias~~. ~~But~~ a programmer can then examine		SyncFinder has shown promise for the future of bug detection, as it has a high success rate in a previously unsuccessful field, on average finding 96% of ad hoc synchronizations. In addition, it can be used to improve other tools, shown when it reduced Valgrind data race checker's false positives by 43%-86%. On the downside, SynchFinder produces 6% false positives.However, this number is relatively small, and the reason for false positives is due to lack of source code on library functions and incorrect pointer aliasing. Even then, a programmer can then examine the returned ad hoc synchronizations to review them for false positives.
	the returned ad hoc synchronizations to review them for false positives. ~~It also requires source code of the application being tested but it was designed for programmers of the applications who have access.~~
	~~SynchFinder~~ uses the static approach to finding ad hoc synchronizations by analyzing source code. A dynamic approach that uses run-time traces would be more accurate, but would carry a heavier computational load and would require a thorough run through of all possible test cases.		SyncFinder uses the static approach to finding ad hoc synchronizations by analyzing source code. A dynamic approach that uses run-time traces would be more accurate, but would carry a heavier computational load and would require a thorough run through of all possible test cases. Because a static approach naturally debugs a larger amount of the code, it is overall the better choice.

	===Conclusion===		===Conclusion===
	The paper's extensive examination of the previously unstudied ad hoc synchronizations concludes that they are prevalent in today's concurrent software, problematic and should be avoided. The basis of their study is well supported with diverse programs, but could always have used more.		The paper's extensive examination of the previously unstudied ad hoc synchronizations concludes that: they are prevalent in today's concurrent software, they are problematic, and they should be avoided. The basis of their study is well supported with diverse programs, but could always have used more.

			Despite the fact that it used a relatively small amount of applications as the basis for the study, the fact that it was able to detect ad hoc synchronizations in software they had not previously analyzed is very impressive. Remarkable still is that it uncovered several major bugs in popular applications that had previously gone undiscovered. The fact that ad hoc synchronizations are fairly sparse (86 being the most they found), the false positive rate is acceptable, as it only means the manual analysis of a few dozen loops at most. The static approach allows the analysis of the entire code base, and with a success rate of 96%, the possible loss of precision is acceptable.

	~~SynchFinder is an effective tool for discovering~~ ad hoc synchronizations ~~with a high success rate~~ and ~~minimal requirements and bolster existing~~ tools ~~efforts at detecting bugs~~.		Overall, both the study regarding the harm of ad hoc synchronizations and the way in which they are detected has been enlightening. It shows both the practices involved in specialized debugging tools, as well as the importance of standardized approaches to concurrency.

	==References==		==References==

Cha0s: /* Critique */

2010-12-03T11:16:24Z

Critique

← Older revision		Revision as of 11:16, 3 December 2010
Line 118:		Line 118:
	==Critique==		==Critique==
	===Style===		===Style===
	There is some unnecessary repetition in two sections of the essay, they ~~list~~ their findings ~~from the study in the contribution section, but~~ in the section that covers the characteristics of ad hoc synchronizations~~, they~~ essentially ~~repeat~~ themselves ~~with their previous findings. The~~ two sections ~~could~~ have been ~~combined~~.		There is some unnecessary repetition in two sections of the essay. In the "Contributions" section, they present the findings of their study. These findings are presented for a second time in the section that covers the characteristics of ad hoc synchronizations. Instead of essentially repeating themselves in two separate sections, it would have been better to refer to the previous section as they make their point.

	===Evaluation===		===Evaluation===

Cha0s: /* Contribution */

2010-12-03T11:12:21Z

Contribution

← Older revision		Revision as of 11:12, 3 December 2010
Line 102:		Line 102:

	====Uses====		====Uses====
	SyncFinder is a robust tool that can be utilized in a variety of applications such as bug detection, performance profiling and concurrency testing. Using its auto-annotation feature, it is capable of identifying sections of code that demonstrate bad programming practices, which could in turn cause issues such as deadlocks. In addition to this, the authors of the paper were able to expand upon the existing data race detector “Valgrind” ~~in order~~ to take advantage of the annotation system introduced by SyncFinder. Through this, the authors were able to reduce the number of false positives flagged by the former, while being able to make use of the information it provides.		SyncFinder is a robust tool that can be utilized in a variety of applications such as bug detection, performance profiling, and concurrency testing. Using its auto-annotation feature, it is capable of identifying sections of code that demonstrate bad programming practices, which could in turn cause issues such as deadlocks. In addition to this, the authors of the paper were able to expand upon the existing data race detector “Valgrind”, modifying it to take advantage of the annotation system introduced by SyncFinder. Through this, the authors were able to reduce the number of false positives flagged by the former, while being able to make use of the information it provides.

	====Accuracy====		====Accuracy====
	SyncFinder was tested against 25 concurrent programs that are used ~~across a broad cross-section of applications~~. In testing, SyncFinder was able to positively identify 96% of ad hoc synchronizations within the tested programs. False positives were at a rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.		SyncFinder was tested against 25 concurrent programs that are commonly used. In testing, SyncFinder was able to positively identify 96% of ad hoc synchronizations within the tested programs. False positives were at a rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

	====Related Work and similar tools====		====Related Work and similar tools====

Cha0s: /* How it works */

2010-12-03T11:09:49Z

How it works

← Older revision		Revision as of 11:09, 3 December 2010
Line 87:		Line 87:
	SyncFinder tracks down ad hoc synchronizations by executing the following steps:		SyncFinder tracks down ad hoc synchronizations by executing the following steps:

	1. Find Loops		1. Find Loops: An important characteristic of ad hoc synchronizations is that they are all implemented using loops, be they “for”, “while” or “go to” loops. These are generally referred to as "sync loops". The first step in identifying sync loops is identifying each loop and obtaining the exit conditions of the loop, using the LLVM infrastructure.

	An important ~~commonality~~ between ~~all~~ ad hoc ~~synchronizations is that they are all caused by loops, be they “for”, “while” or “go to”~~ loops. ~~These are generally referred to as "sync loops". The first step in identifying sync loops is The LLVM infrastructure is used to obtain~~ the ~~loop info from the source including a representation of the exit conditions.~~		2. Identify Sync Loops: The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:

	2. ~~Identify Sync Loops~~		* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is an implementation of ad hoc synchronization.

	~~The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:~~
	* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
	* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.		* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.

	* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that calls cond_wait inside the loop.		* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that calls cond_wait inside the loop.

	3. Synchronization Pairing		3. Synchronization Pairing: The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently, as they would not affect each other. This is done conservatively due to the limitations of static analysis.

	The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

	~~4. SyncFinder Annotation~~

	After the initial set of loops found is ~~culled~~ through the above process, the remaining loops are determined to be sync loops, and are suitably annotated. Marking the source code with LLVM’s static instrumentation framework, it allows for other tools to take advantage of SyncFinder’s findings in their own analysis.		4. SyncFinder Annotation: After the initial set of loops found is reduced through the above process, the remaining loops are determined to be sync loops, and are suitably annotated. Marking the source code with LLVM’s static instrumentation framework, it allows for other tools to take advantage of SyncFinder’s findings in their own analysis.

	====Uses====		====Uses====

Cha0s: /* Contribution */

2010-12-03T11:02:11Z

Contribution

← Older revision		Revision as of 11:02, 3 December 2010
Line 80:		Line 80:

	===SyncFinder===		===SyncFinder===
	SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this ~~was~~ to aid programmers in better ~~structuring their code~~, ~~while simultaneously allowing for other~~ tools ~~to be utilized,~~ recognizing ~~them as synchronizations~~. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronizations.		SyncFinder is a tool built and designed by the authors of the paper, for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C/C++. The main goal of this is to aid programmers in better handling synchronization, as well as assisting debugging tools in recognizing ad hoc synchronization. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronizations.

	====How it works====		====How it works====
	There are two possibilities to consider when searching for ad hoc synchronizations. You can either analyze runtime traces via a dynamic method, or analyze the source code in a static method. Both methods carry with them a number of pros and cons. While a dynamic process is generally more accurate than a static method, ~~it tends to accrue~~ a ~~very large runtime~~ overhead. In addition to this, the dynamic method is somewhat limited ~~in which~~ ad hoc synchronizations ~~it can find by the code coverage of~~ the test cases. Taking these factors into consideration, the authors of the paper opted to pursue a static solution for achieving the goals set out for SyncFinder. SyncFinder uses the LLVM compiler infrastructure.		There are two possibilities to consider when searching for ad hoc synchronizations. You can either analyze runtime traces via a dynamic method, or analyze the source code in a static method. Both methods carry with them a number of pros and cons. While a dynamic process is generally more accurate than a static method, there is a significant overhead, affecting performance. In addition to this, the dynamic method is somewhat limited as it can only detect ad hoc synchronizations demonstrated in the test cases. Taking these factors into consideration, the authors of the paper opted to pursue a static solution for achieving the goals set out for SyncFinder. SyncFinder uses the LLVM compiler infrastructure.

			SyncFinder tracks down ad hoc synchronizations by executing the following steps:

	1. Find Loops		1. Find Loops

Cha0s: /* Findings */

2010-12-03T10:54:55Z

Findings

← Older revision		Revision as of 10:54, 3 December 2010
Line 69:		Line 69:
	This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the form of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.		This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the form of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

	5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing them. Some typical characteristics of an ad hoc synchronization ~~follow.~~		5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing them. Some typical characteristics of an ad hoc synchronization include:

	* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.		* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.

	* Often, exit conditions depend on sync variables (variables that are shared with other tasks).		* Often, exit conditions depend on sync variables (variables that are shared with other tasks).

	* In some cases, the synchronization does not wait idly, performing other computations while checking the sync variables periodically.		* In some cases, the synchronization does not wait idly, performing other computations while checking the sync variables periodically.

Cha0s: /* Findings */

2010-12-03T10:54:06Z

Findings

Cha0s: /* Findings */

2010-12-03T10:43:09Z

Findings

← Older revision		Revision as of 10:43, 3 December 2010
Line 58:		Line 58:
	1. In all programs studied, it was found that each contained numerous ad hoc synchronizations. The number of synchronizations found ranged from 6 to 83, with server-type programs containing the most. It is likely that programmers use this type of synchronization for two reasons:		1. In all programs studied, it was found that each contained numerous ad hoc synchronizations. The number of synchronizations found ranged from 6 to 83, with server-type programs containing the most. It is likely that programmers use this type of synchronization for two reasons:

	* In order to ensure ~~a certain~~ order ~~of execution in the case of a concurrent system~~, programmers will use ad hoc synchronization to ~~superimpose this order~~. ~~With traditional~~ synchronization ~~techniques,~~ this ~~can vary between systems. As the~~ order ~~can vary, it is difficult to create a common interface~~.		* In order to ensure processes execute in proper order, programmers will use ad hoc synchronization to ensure processes wait for their turn. The reason for using ad hoc synchronization over standardized mechanisms is to fully customize the handling of this execution order.

	* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this ~~and supposedly~~ protect performance.		* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this in order to protect performance.

	2. ~~Often, it~~ is very hard to identify an ad hoc ~~loop as a~~ synchronization ~~method~~. They are hard to distinguish from other computational loops and as the implementations are diverse, it is ~~hard~~ to ~~pinpoint them~~ from the code. ~~This can make~~ the ~~system hard~~ to ~~maintain~~, ~~as other programmers will not be able to identify~~ ad hoc ~~loops implemented by another and debugging programs cannot recognize them as issues~~.		2. It is often very hard to identify instances of ad hoc synchronization. They are hard to distinguish from other computational loops and as the implementations are diverse, there is no easy way to differentiate it from harmless code. As they are difficult to detect, they will go unnoticed by anyone modifying the code base. Since they are unaware of the ad hoc loop, they may unknowingly introduce bugs. As well, due to their stealthy nature, standard debugging tools have a hard time of identifying ad hoc synchronizations.

	3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.		3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

← Older revision		Revision as of 10:54, 3 December 2010
Line 54:		Line 54:
	===Findings===		===Findings===

	In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were ~~examined to find instances of ad hoc synchronizations~~. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these ~~characteristics of~~ ad hoc synchronizations were ~~found~~:		In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were analyzed. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these facts regarding ad hoc synchronizations were discovered:

	1. In all programs studied, it was found that each contained numerous ad hoc synchronizations. The number of synchronizations found ranged from 6 to 83, with server-type programs containing the most. It is ~~likely~~ that programmers use ~~this type of~~ synchronization for two reasons:		1. In all programs studied, it was found that each contained numerous ad hoc synchronizations. The number of synchronizations found ranged from 6 to 83, with server-type programs containing the most. It is proposed that programmers tend to use ad hoc synchronization for two reasons:

	* In order to ensure processes execute in proper order, programmers will use ad hoc synchronization to ensure processes wait for their turn. The reason for using ad hoc synchronization over standardized mechanisms is to fully customize the handling of this execution order.		* In order to ensure processes execute in proper order, programmers will use ad hoc synchronization to ensure processes wait for their turn. The reason for using ad hoc synchronization over standardized mechanisms is to fully customize the handling of this execution order.

	* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations ~~to avoid this~~ in order to ~~protect~~ performance.		* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations in order to improve performance.

	2. It is often very hard to identify instances of ad hoc synchronization. They are hard to distinguish from other computational loops and as the implementations are diverse, there is no easy way to differentiate it from harmless code. As they are difficult to detect, they will go unnoticed by anyone modifying the code base. Since they are unaware of the ad hoc loop, they may unknowingly introduce bugs. As well, due to their stealthy nature, standard debugging tools have a hard time of identifying ad hoc synchronizations.		2. It is often very hard to identify instances of ad hoc synchronization. They are hard to distinguish from other computational loops and as the implementations are diverse, there is no easy way to differentiate them from harmless code. As they are difficult to detect, they will go unnoticed by anyone modifying the code base. Since they are unaware of the ad hoc loop, they may unknowingly introduce bugs. As well, due to their stealthy nature, standard debugging tools have a hard time of identifying ad hoc synchronizations.

	3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them ~~if they were not first identified either manually or automatically~~.		3. It was found that ad hoc synchronizations often introduce bugs into the system, such as deadlocks or hangs. Since these are different than those caused by locks and other synchronizations, it is hard for detection tools to recognize them.

	4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by ~~using~~ ad hoc ~~synchronization~~. Since they cannot find these problems, it severely impacts the effectiveness of such tools.		4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives, as the tool is unaware of the "work arounds" put into affect by the ad hoc implementation. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
	This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the form of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.		This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the form of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

	5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing them. Some typical characteristics of an ad hoc synchronization follow.		5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing them. Some typical characteristics of an ad hoc synchronization follow.
	* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.		* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
	* Often, exit conditions depend on sync variables, variables that are shared with other tasks		* Often, exit conditions depend on sync variables (variables that are shared with other tasks).
	* In some cases, the synchronization does not wait idly ~~and rather performs~~ other computations while checking the sync variables periodically.		* In some cases, the synchronization does not wait idly, performing other computations while checking the sync variables periodically.

	Despite the dangers of using ad hoc synchronization, programmers continue to use this method. ~~It is found that, in comments,~~ programmers ~~have stated~~ that ~~possibly~~ their implementations are unsafe but proceed to use ad hoc synchronization techniques anyway~~. The reasoning behind these decisions have already been outlined in point 1~~. A better practice of synchronization would be to replace ad hoc synchronizations with synchronization primitives, primitives already present in standard POSIX thread libraries. However, it is often difficult to replace ad hoc synchronizations with synchronization primitives and doing this may not fulfill the concerns presented in point 1.		Despite the dangers of using ad hoc synchronization, programmers continue to use this method. Comments added by programmers indicate that their implementations are potentially unsafe, but proceed to use ad hoc synchronization techniques anyway, due to reasons outline above. A better practice of synchronization would be to replace ad hoc synchronizations with synchronization primitives (primitives already present in standard POSIX thread libraries). However, it is often difficult to replace ad hoc synchronizations with synchronization primitives and doing this may not fulfill the concerns presented in point 1.

	===SyncFinder===		===SyncFinder===