Java Monitor - Revision history

JaroslavTulach at 08:45, 7 September 2009

2009-09-07T08:45:39Z

←Older revision		Revision as of 08:45, 7 September 2009
Line 46:		Line 46:
	<source lang="java" snippet="monitor.pitfalls.brokencall"/>		<source lang="java" snippet="monitor.pitfalls.brokencall"/>

-	can never [[deadlock]] again, regardless how bad or clueless [[API]] clients one has~~. In the name of [[cluelessness]] of your [[Java]] [[API]] users, don't forget to prefer private locks to '''synchronized''' methods~~.	+	can never [[deadlock]] again, regardless how bad or clueless [[API]] clients one has.

-	~~<comments/>~~	+	=== The way out ===
		+
		+	{{:Synchronized}}
		+
		+	[[Category:APIDesignPatterns]]
		+	[[Category:APIDesignPatterns:Anti]]

JaroslavTulach: /* Implications for API Design */

2009-02-12T10:10:51Z

Implications for API Design

←Older revision		Revision as of 10:10, 12 February 2009
Line 36:		Line 36:
	Now, after blaming [[Java]] of having wrong synchronization model, it is our turn to explain what implications does this have for [[API]] design. Are the above described problems reason why one cannot write good [[API]] in [[Java]]? No, not at all. One just cannot do it [[Cluelessness\|cluelessly]], one cannot use the most obvious tool - '''synchronized''' methods - when writing a shared library.		Now, after blaming [[Java]] of having wrong synchronization model, it is our turn to explain what implications does this have for [[API]] design. Are the above described problems reason why one cannot write good [[API]] in [[Java]]? No, not at all. One just cannot do it [[Cluelessness\|cluelessly]], one cannot use the most obvious tool - '''synchronized''' methods - when writing a shared library.

-	Exposing locks in an [[API]] has its own obligations. Other people can obtain them and the [[API]] has to know what to do ~~that~~. Having some global, publicly accessible locks is a way to ask for problems with [[deadlock]]s.	+	Exposing locks in an [[API]] has its own obligations. Other people can obtain them and the [[API]] has to know what to do then. Having some global, publicly accessible locks exposed to unknown clients is a way to ask for problems with [[deadlock]]s.

-	Using ''synchronized'' methods in classes accessible to [[API]] clients ~~also exposes these monitors to~~ public. Moreover often unconsciously, which is even more dangerous. The fix is simple. Just hide the locks as private objects:	+	Using ''synchronized'' methods in classes makes the locks accessible to [[API]] clients for public use. Moreover this often happens unconsciously, which is even more dangerous. The fix is simple. Just hide the locks as private objects:

	<source lang="java" snippet="monitor.pitfalls.CacheOK"/>		<source lang="java" snippet="monitor.pitfalls.CacheOK"/>
Line 46:		Line 46:
	<source lang="java" snippet="monitor.pitfalls.brokencall"/>		<source lang="java" snippet="monitor.pitfalls.brokencall"/>

-	can never [[deadlock]] again, regardless how bad of clueless [[API]] clients one has. In the name of [[cluelessness]] of your [[Java]] [[API]] users, don't forget to prefer private locks to '''synchronized''' methods.	+	can never [[deadlock]] again, regardless how bad or clueless [[API]] clients one has. In the name of [[cluelessness]] of your [[Java]] [[API]] users, don't forget to prefer private locks to '''synchronized''' methods.
		+
		+	<comments/>

JaroslavTulach at 10:08, 12 February 2009

2009-02-12T10:08:26Z

JaroslavTulach: /* Implications for API Design */

2009-02-12T06:08:55Z

Implications for API Design

←Older revision		Revision as of 06:08, 12 February 2009
Line 30:		Line 30:
	=== Implications for [[API]] Design ===		=== Implications for [[API]] Design ===

-	~~TBD: Use internal~~ locks	+	Now, after blaming [[Java]] of having wrong synchronization model, it is our turn to explain what implications does this have for [[API]] design. Are the above described problems reason why one cannot write good [[API]] in [[Java]]? No, not at all. One just cannot do it [[Cluelessness\|cluelessly]], one cannot use the most obvious tool - '''synchronized''' methods - when writing a shared library.
		+
		+	Exposing locks in an [[API]] has its own obligations. Other people can obtain them and the [[API]] has to know what to do that. Having some global, publicly accessible locks is a way to ask for problems with [[deadlock]]s.
		+
		+	Using ''synchronized'' methods in classes accessible to [[API]] clients also exposes these monitors to public. Moreover often unconsciously, which is even more dangerous. The fix is simple. Just hide the locks as private objects:
		+
		+	// TBD
		+
		+	With a change like this the call
		+
		+	<source lang="java" snippet="monitor.pitfalls.brokencall"/>
		+
		+	can never [[deadlock]] again, regardless how bad [[API]] clients one has.

JaroslavTulach at 10:00, 11 February 2009

2009-02-11T10:00:42Z

←Older revision		Revision as of 10:00, 11 February 2009
Line 26:		Line 26:
	<source lang="java" snippet="monitor.pitfalls.block.propertychange"/>		<source lang="java" snippet="monitor.pitfalls.block.propertychange"/>

-	Simple call to '''get("123")''' deadlocks. Why? Because the [[Java Monitor]]s implant the [[monitor]] concept into object oriented world and in the process of doing ~~that~~ break the most fundamental assumption: the [[monitor]] shall be encapsulated. One shall always define all internal data structures and operations working on them in one monitor.	+	Simple call to '''get("123")''' deadlocks. Why? Because the [[Java Monitor]]s implant the [[monitor]] concept into object oriented world and in the process of doing so break the most fundamental assumption: the [[monitor]] shall be encapsulated. One shall always define all internal data structures and operations working on them in one monitor. This is not the case of [[Java]]'s synchronized methods at all. By default, the '''Cache''' and its subclass '''MultiplyCache''' share the same [[monitor]] lock!

-	// TBD	+	=== Implications for [[API]] Design ===
		+
		+	TBD: Use internal locks

JaroslavTulach at 07:51, 11 February 2009

2009-02-11T07:51:32Z

←Older revision		Revision as of 07:51, 11 February 2009
Line 1:		Line 1:
-	The [[Java]] synchronization model with all '''synchronized''', '''notify''' and '''wait''' its is commonly thought of as an example of [[monitor]]s. However with closer look one finds out that it is far different to the model used in [[wikipedia::Concurrent_Pascal\|Concurrent Pascal]]. It is not that robust, it is not well enough integrated to the language and sort of feels like an assembly language with synchronization primitives than high-level abstraction provided by real [[monitor]]. However, it has yet another hidden flaw, kind of example of [[~~CopyBasedDesign~~]] problem: the [[Java Monitor]]s implant the [[monitor]] into [[wikipedia::Object_oriented_language\|object oriented language]], in an object oriented style and that does not work.	+	The [[Java]] synchronization model with all '''synchronized''', '''notify''' and '''wait''' its is commonly thought of as an example of [[monitor]]s. However with closer look one finds out that it is far different to the model used in [[wikipedia::Concurrent_Pascal\|Concurrent Pascal]]. It is not that robust, it is not well enough integrated to the language and sort of feels like an assembly language with synchronization primitives than high-level abstraction provided by real [[monitor]]. However, it has yet another hidden flaw, kind of example of [[Copy Based Design]] problem: the [[Java Monitor]]s implant the [[monitor]] into [[wikipedia::Object_oriented_language\|object oriented language]], in an object oriented style and that does not work.

	Imagine there is an '''Cache''' support class in some [[API]]:		Imagine there is an '''Cache''' support class in some [[API]]:

-	/~~/ TBD~~	+	<source lang="java" snippet="monitor.pitfalls.Cache"/>

	Its synchronization is sufficiently well designed. It never calls foreign code while holding own lock, which is one of necessary [[Deadlock Condition]]s. As such one would expect that there is no way to [[deadlock]] on the '''Cache'''s lock. However that would be false assumption. Simple call like:		Its synchronization is sufficiently well designed. It never calls foreign code while holding own lock, which is one of necessary [[Deadlock Condition]]s. As such one would expect that there is no way to [[deadlock]] on the '''Cache'''s lock. However that would be false assumption. Simple call like:

-	/~~/ TBD~~	+	<source lang="java" snippet="monitor.pitfalls.brokencall"/>

-	can lead to [[deadlock]]~~. Moreover this all is achievable using the~~ ''~~best~~'' ~~[[Java]] synchronization practices. Just imagine there is a subclass of the '''Cache~~''' ~~class which defines few properties and for better or worse guards them as~~ [[~~Java Monitor~~]]:	+	can lead to [[deadlock]] while waiting to enter internal(!) '''Cache''''s [[monitor]]:

-	// ~~TBD~~	+	<source lang="text">
		+	Thread Test Watch Dog: testDeadlockViaAPI
		+	org.apidesign.javamonitorflaws.Cache.inspectValue:32
		+	org.apidesign.javamonitorflaws.Cache.get:22
		+	org.apidesign.javamonitorflaws.CacheTest.testDeadlockViaAPI:134
		+	</source>
		+
		+	Moreover this all is achievable using the ''best'' [[Java]] synchronization practices. Just imagine there is a subclass of the '''Cache''' class which defines few properties and for better or worse guards them as [[Java Monitor]]:
		+
		+	<source lang="java" snippet="monitor.pitfalls.subclass"/>

	This code is not bulletproof. It notifies its listeners while holding own lock and as such this can lead to deadlocks. However it is common that people do these sort of mistakes when using an [[API]]. The [[API]] shall be ready to handle [[cluelessness\|clueless]] clients. It is acceptable to let the clients of an [[API]] deadlock on their own locks, yet there is no reason to block the [[API]] itself. Yet this is the case:		This code is not bulletproof. It notifies its listeners while holding own lock and as such this can lead to deadlocks. However it is common that people do these sort of mistakes when using an [[API]]. The [[API]] shall be ready to handle [[cluelessness\|clueless]] clients. It is acceptable to let the clients of an [[API]] deadlock on their own locks, yet there is no reason to block the [[API]] itself. Yet this is the case:

-	/~~/ TBD~~	+	<source lang="java" snippet="monitor.pitfalls.block.propertychange"/>

	Simple call to '''get("123")''' deadlocks. Why? Because the [[Java Monitor]]s implant the [[monitor]] concept into object oriented world and in the process of doing that break the most fundamental assumption: the [[monitor]] shall be encapsulated. One shall always define all internal data structures and operations working on them in one monitor.		Simple call to '''get("123")''' deadlocks. Why? Because the [[Java Monitor]]s implant the [[monitor]] concept into object oriented world and in the process of doing that break the most fundamental assumption: the [[monitor]] shall be encapsulated. One shall always define all internal data structures and operations working on them in one monitor.

	// TBD		// TBD

JaroslavTulach: New page: The Java synchronization model with all '''synchronized''', '''notify''' and '''wait''' its is commonly thought of as an example of monitors. However with closer look one finds ou...

2009-02-11T07:15:10Z

New page: The Java synchronization model with all '''synchronized''', '''notify''' and '''wait''' its is commonly thought of as an example of monitors. However with closer look one finds ou...

New page

The [[Java]] synchronization model with all '''synchronized''', '''notify''' and '''wait''' its is commonly thought of as an example of [[monitor]]s. However with closer look one finds out that it is far different to the model used in [[wikipedia::Concurrent_Pascal|Concurrent Pascal]]. It is not that robust, it is not well enough integrated to the language and sort of feels like an assembly language with synchronization primitives than high-level abstraction provided by real [[monitor]]. However, it has yet another hidden flaw, kind of example of [[CopyBasedDesign]] problem: the [[Java Monitor]]s implant the [[monitor]] into [[wikipedia::Object_oriented_language|object oriented language]], in an object oriented style and that does not work.

Imagine there is an '''Cache''' support class in some [[API]]:

// TBD

Its synchronization is sufficiently well designed. It never calls foreign code while holding own lock, which is one of necessary [[Deadlock Condition]]s. As such one would expect that there is no way to [[deadlock]] on the '''Cache'''s lock. However that would be false assumption. Simple call like:

// TBD

can lead to [[deadlock]]. Moreover this all is achievable using the ''best'' [[Java]] synchronization practices. Just imagine there is a subclass of the '''Cache''' class which defines few properties and for better or worse guards them as [[Java Monitor]]:

// TBD

This code is not bulletproof. It notifies its listeners while holding own lock and as such this can lead to deadlocks. However it is common that people do these sort of mistakes when using an [[API]]. The [[API]] shall be ready to handle [[cluelessness|clueless]] clients. It is acceptable to let the clients of an [[API]] deadlock on their own locks, yet there is no reason to block the [[API]] itself. Yet this is the case:

// TBD

Simple call to '''get("123")''' deadlocks. Why? Because the [[Java Monitor]]s implant the [[monitor]] concept into object oriented world and in the process of doing that break the most fundamental assumption: the [[monitor]] shall be encapsulated. One shall always define all internal data structures and operations working on them in one monitor.

// TBD

←Older revision		Revision as of 10:08, 12 February 2009
Line 1:		Line 1:
-	The [[Java]] synchronization model with all '''synchronized''', '''notify''' and '''wait''' ~~its~~ is commonly thought of as an example of [[monitor]]s. However with closer look one finds out that it is far different to the model used in [[wikipedia::Concurrent_Pascal\|Concurrent Pascal]]. It is not that robust, it is not well enough integrated to the language and sort of feels like an assembly language with synchronization primitives than high-level abstraction provided by real [[monitor]]. However, it has yet another hidden flaw, kind of example of [[Copy Based Design]] problem: the [[Java Monitor]]s implant the [[monitor]] into [[wikipedia::Object_oriented_language\|object oriented language]], in an object oriented style and that does not work.	+	The [[Java]] synchronization model with all its '''synchronized''', '''notify''' and '''wait''' is commonly thought of as an example of [[monitor]]s. However with closer look one finds out that it is far different to the model used in [[wikipedia::Concurrent_Pascal\|Concurrent Pascal]]. It is not that robust, it is not well enough integrated to the language and sort of feels like an assembly language with synchronization primitives than high-level abstraction provided by real [[monitor]]. However, it has yet another hidden flaw, kind of example of [[Copy Based Design]] problem: the [[Java Monitor]]s implant the [[monitor]] into [[wikipedia::Object_oriented_language\|object oriented language]], in an object oriented style and that does not work.

	Imagine there is an '''Cache''' support class in some [[API]]:		Imagine there is an '''Cache''' support class in some [[API]]:
Line 5:		Line 5:
	<source lang="java" snippet="monitor.pitfalls.Cache"/>		<source lang="java" snippet="monitor.pitfalls.Cache"/>

-	Its synchronization is sufficiently well designed. It never calls foreign code while holding own lock, which is one of necessary [[Deadlock Condition]]s. As such one would expect that there is no way to [[deadlock]] on the '''Cache'''s lock. However that would be false assumption. Simple call like:	+	Its synchronization is sufficiently well designed. It never calls foreign code while holding own lock, which is one of necessary [[Deadlock Condition]]s. As such one would expect that there is no way to [[deadlock]] on the '''Cache''''s own lock. However that would be false assumption. Simple call like:

	<source lang="java" snippet="monitor.pitfalls.brokencall"/>		<source lang="java" snippet="monitor.pitfalls.brokencall"/>
Line 18:		Line 18:
	</source>		</source>

-	Moreover this all is achievable using the ''best'' [[Java]] synchronization practices. Just imagine there is a subclass of the '''Cache''' class which defines few properties and for better or worse guards them as [[Java Monitor]]:	+	Moreover this all is achievable using the ''best'' [[Java]] synchronization practices. How's that possible?
		+
		+	Just imagine there is a subclass of the '''Cache''' class which defines few properties and for better or worse guards them as [[Java Monitor]]:

	<source lang="java" snippet="monitor.pitfalls.subclass"/>		<source lang="java" snippet="monitor.pitfalls.subclass"/>

-	This code is not bulletproof. It notifies its listeners while holding own lock and as such this can lead to deadlocks. However it is common that people do these sort of mistakes when using an [[API]]. The [[API]] shall be ready to handle [[cluelessness\|clueless]] clients. It is acceptable to let ~~the clients of an [[API]]~~ deadlock on their own locks, yet there is no reason to block the [[API]] itself. Yet this is the case:	+	This code is not bulletproof. It notifies its listeners while holding own lock and as such this can lead to deadlocks. However it is common that people do these sort of mistakes when using an [[API]]. The [[API]] shall be ready to handle such [[cluelessness\|clueless]] clients. It is acceptable to let them deadlock on their own locks, yet there is no reason to block the [[API]] itself. It shall continue to work for other clients if possible. Yet this is the case in this example:

	<source lang="java" snippet="monitor.pitfalls.block.propertychange"/>		<source lang="java" snippet="monitor.pitfalls.block.propertychange"/>

-	Simple call to '''get("123")''' deadlocks. Why? Because the [[Java Monitor]]s implant the [[monitor]] concept into object oriented world and in the process of doing so break the most fundamental assumption: the [[monitor]] shall be encapsulated. One shall always define all internal data structures and operations working on them in one monitor. This is not the case of [[Java]]'s synchronized methods at all. By default, the '''Cache''' and its subclass '''MultiplyCache''' share the same [[monitor]] lock!	+	Simple call to '''get("123")''' deadlocks. Why? Because the [[Java Monitor]]s implant the [[monitor]] concept into object oriented world and in the process of doing so break the most fundamental assumption: the [[monitor]] shall be encapsulated.
		+
		+	One shall always define all internal data structures and all their operations working on them in one monitor. This is not the case of [[Java]]'s synchronized methods at all. By default, the methods in '''Cache''' and its subclass '''MultiplyCache''' share the same [[monitor]] lock!

	=== Implications for [[API]] Design ===		=== Implications for [[API]] Design ===
Line 36:		Line 40:
	Using ''synchronized'' methods in classes accessible to [[API]] clients also exposes these monitors to public. Moreover often unconsciously, which is even more dangerous. The fix is simple. Just hide the locks as private objects:		Using ''synchronized'' methods in classes accessible to [[API]] clients also exposes these monitors to public. Moreover often unconsciously, which is even more dangerous. The fix is simple. Just hide the locks as private objects:

-	/~~/ TBD~~	+	<source lang="java" snippet="monitor.pitfalls.CacheOK"/>

	With a change like this the call		With a change like this the call
Line 42:		Line 46:
	<source lang="java" snippet="monitor.pitfalls.brokencall"/>		<source lang="java" snippet="monitor.pitfalls.brokencall"/>

-	can never [[deadlock]] again, regardless how bad [[API]] clients one has.	+	can never [[deadlock]] again, regardless how bad of clueless [[API]] clients one has. In the name of [[cluelessness]] of your [[Java]] [[API]] users, don't forget to prefer private locks to '''synchronized''' methods.