Locking Issues - Revision history

Monica at 11:46, 4 November 2013

2013-11-04T11:46:31Z

Dana: /* Special debugging options */

2012-11-20T15:00:14Z

‎Special debugging options

Dana: /* Debugging mutex issues */

2012-11-19T12:36:44Z

‎Debugging mutex issues

Dana: /* Debugging mutex issues */

2012-11-19T12:30:36Z

‎Debugging mutex issues

Dana: /* Debugging mutex issues */

2012-11-19T12:29:18Z

‎Debugging mutex issues

Dana: /* Deadlocks */

2012-11-19T12:26:23Z

‎Deadlocks

Dana: /* Deadlocks */

2012-11-19T12:25:52Z

‎Deadlocks

Dana: /* Lack of locking */

2012-11-19T12:25:23Z

‎Lack of locking

Dana: Created page with " Countless bugs can result from improper locking resources. Yate being a multithreaded program a multitude of problems can occur from bad programming. For developers' help th..."

2012-11-19T12:24:51Z

Created page with " Countless bugs can result from improper locking resources. Yate being a multithreaded program a multitude of problems can occur from bad programming. For developers' help th..."

New page

Countless bugs can result from improper locking resources. Yate being a multithreaded program a multitude of problems can occur from bad programming.

For developers' help this page tries to provide an overview of problems caused by improper locking and how to troubleshoot them.

=== Lack of locking===

A lack of proper resource locking usually leads to a [[http://en.wikipedia.org/wiki/Race_condition#Computing|race condition]] when the order of some operations is not guaranteed.

The effect can range from subtle (counters not properly incremented) to dramatic program crashes if one thread alter other's pointers.

=== Deadlocks===

A [[http://en.wikipedia.org/wiki/Deadlock|deadlock]] situation occurs when one or more threads are trying to acquire two or more [[Mutexes and locking]] waiting for each other to finish. Since each is trying to acquire other's lock while holding its own locked this situation never ends.

The typical symptom of a deadlock is that the program (or part of it) stop responding.

=== Debugging mutex issues===

Debugging multithreaded programs is a difficult task since usually the problems occur infrequently. There can be millions of iterations until a detectable problem actually occurs.

Yate has some builtin support for debugging deadlocks in its base classes. Threads that exit while holding a mutex or while trying to acquire one will issue a [[Debug Output#DebugFail|DebugFail]] message. Mutexes hold the name and address of the thread that acquired them, provided the thread was created by a Yate '''Thread''' object and not from some library.

The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output#DebugFail|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name.

'''See also'''

*[[Mutexes and locking]]
*[[Debug Output]]

← Older revision		Revision as of 11:46, 4 November 2013
Line 32:		Line 32:
	* [[Mutexes and locking]]		* [[Mutexes and locking]]
	* [[Debug Output]]		* [[Debug Output]]
		+
		+	[[Category:Programmers]] [[Category:Locking]]

← Older revision		Revision as of 15:00, 20 November 2012
Line 25:		Line 25:

	The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output#Debugging_levels\|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name.		The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output#Debugging_levels\|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name.
		+

	'''See also'''		'''See also'''

@@ Line 21: / Line 21: @@
 Yate has some builtin support for debugging deadlocks in its base classes. Threads that exit while holding a mutex or while trying to acquire one will issue a [[Debug Output#Debugging_levels|DebugFail]] message. Mutexes hold the name and address of the thread that acquired them, provided the thread was created by a Yate '''Thread''' object and not from some library.
 The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output#Debugging_levels|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name.
@@ Line 26: / Line 28: @@
 '''See also'''
-*[[Mutexes and locking]]
+* [[Starting Yate]]
-*[[Debug Output]]
+* [[Mutexes and locking]]

@@ Line 20: / Line 20: @@
 Debugging multithreaded programs is a difficult task since usually the problems occur infrequently. There can be millions of iterations until a detectable problem actually occurs.
-Yate has some builtin support for debugging deadlocks in its base classes. Threads that exit while holding a mutex or while trying to acquire one will issue a [[Debug Output##Debugging_levels|DebugFail]] message. Mutexes hold the name and address of the thread that acquired them, provided the thread was created by a Yate '''Thread''' object and not from some library.
+Yate has some builtin support for debugging deadlocks in its base classes. Threads that exit while holding a mutex or while trying to acquire one will issue a [[Debug Output#Debugging_levels|DebugFail]] message. Mutexes hold the name and address of the thread that acquired them, provided the thread was created by a Yate '''Thread''' object and not from some library.
-The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output##Debugging_levels|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name.
+The '''-Dm''' command line option makes lock operation abort after 10 seconds with a [[Debug Output#Debugging_levels|DebugFail]] level message. Associated with the '''-Da''' and '''-C''' (POSIX only) options this allows Yate to crash immediately when the deadlock is detected and provide a hopefully usable core dump. The call stack will provide the code path of the thread that detected the deadlock. Unfortunately you will have to make educated guesses about the path taken by the thread that locked the offending mutex but at least you will have its name.
 '''See also'''

@@ Line 12: / Line 12: @@
 === Deadlocks===
-A [http://en.wikipedia.org/wiki/Deadlock deadlock] situation occurs when one or more threads are trying to acquire two or more [[Mutexes and locking]] waiting for each other to finish. Since each is trying to acquire other's lock while holding its own locked this situation never ends.
+A [http://en.wikipedia.org/wiki/Deadlock deadlock] situation occurs when one or more threads are trying to acquire two or more [[Mutexes and locking|Mutexes]] waiting for each other to finish. Since each is trying to acquire other's lock while holding its own locked this situation never ends.
 The typical symptom of a deadlock is that the program (or part of it) stop responding.

@@ Line 6: / Line 6: @@
 === Lack of locking===
-A lack of proper resource locking usually leads to a [[http://en.wikipedia.org/wiki/Race_condition#Computing|race condition]] when the order of some operations is not guaranteed.
+A lack of proper resource locking usually leads to a [http://en.wikipedia.org/wiki/Race_condition#Computing race condition] when the order of some operations is not guaranteed.
 The effect can range from subtle (counters not properly incremented) to dramatic program crashes if one thread alter other's pointers.